[Freeswitch-users] XML DialPlan Gateay dialing redundancy

Wed Dec 26 23:07:46 MSK 2012

The only issue with "standard" is that everyone has his own definition of
what "standard" behavior should be. :) However, I'm not at all opposed to
having a cookbook-style set of recipes for how people have solved this
issue in various scenarios.

-MC

On Wed, Dec 26, 2012 at 11:46 AM, Avi Marcus <avi at avimarcus.net> wrote:

> This seems like such a common case that it's sad we mostly have
> individually built kludges for our bridges.
> Personally, my routing continue on any error, which sometimes results in 3
> different errors from the carriers.
> Sometimes, it's 3 user_busy in a row -- and sometimes 2 busy and then the
> call goes through, so I'm not sure I can even trust user_busy....
>
> Perhaps we can figure out and wikify a "standard" for using attempting via
> multiple carriers for connecting to PSTN...
>
> -Avi
>
> On Wed, Dec 26, 2012 at 8:15 PM, Michael Collins <msc at freeswitch.org>wrote:
>
>> Yeah, that's a fun one. You'll probably need to concoct a configuration
>> making use of continue_on_fail and failure_causes chan vars. You'll also
>> need to figure out all the ways in which each gateway's carrier might fail
>> the call. Oh, and "no answer" is also a "failure" so you'll need to find a
>> way to handle that differently than the other "failure" conditions. Perhaps
>> after each bridge attempt you could all a lua script that checks the value
>> of bridge_hangup_cause and then decide what to do with the call, i.e. on a
>> no answer you could transfer the call to a voicemail extension but on any
>> other failure cause you could simply exit the script and let the dialplan
>> continue processing.
>>
>> Just as a starter maybe something like this:
>>
>> <action application="set" data="continue_on_fail=true"/>
>> <action application="set" data="hangup_after_brdige=false"/>
>> <action application="bridge" data="sofia/gateway/gw1/$1"/>
>> <action application="lua" data="check_cause.lua"/>
>> <action application="bridge" data="sofia/gateway/gw2/$1"/>
>> <action application="lua" data="check_cause.lua"/>
>> <action application="bridge" data="sofia/gateway/gw3/$1"/>
>> <action application="lua" data="check_cause.lua"/>
>>
>> You'll need to make sure the lua script also checks to see if the
>> previous bridge was answered and if so then hangup the call, otherwise it
>> will keep trying the next bridge command.
>>
>> Have fun with that one! :)
>>
>> -Michael
>>
>> On Mon, Dec 24, 2012 at 9:36 AM, Sean Devoy <sdevoy at bizfocused.com>wrote:
>>
>>> ** **
>>>
>>> I need a little help with a complex XML dialplan.  Also, I am on the
>>> Stable release so I do not believe the much needed nested conditions exists
>>> for me yet.****
>>>
>>> ** **
>>>
>>> My problem is faulty gateway providers who periodically fail to connect
>>> the call with [temp failure] because “our routing tables where not up to
>>> date.”****
>>>
>>> ** **
>>>
>>> So what I am after is an xml dialplan to do this****
>>>
>>> If (it is a 10 or 11 digit dial)****
>>>
>>>                 Dial using gateway 1****
>>>
>>>                 If no answer****
>>>
>>>                                 Go to voice mail****
>>>
>>>                 Else if gateway failure ****
>>>
>>>                                 Dial using gateway 2****
>>>
>>>                 If no answer****
>>>
>>>                                 Go to voice mail****
>>>
>>>                 Else if gateway failure ****
>>>
>>>                                 Dial using gateway 3****
>>>
>>>                 If no answer****
>>>
>>>                                 Go to voice mail****
>>>
>>>                                 Else if gateway failure****
>>>
>>>                                                 Play a message that the
>>> number is screwed!****
>>>
>>> ** **
>>>
>>> Perhaps I need to breakdown and use a scripting language like LUA or
>>> JavaScript for this, but I would rather keep everything in XML if possible.
>>> ****
>>>
>>> ** **
>>>
>>> Any thoughts?****
>>>
>>> ** **
>>>
>>> Happy Holidays to all,****
>>>
>>> Sean****
>>>
>>> ** **
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.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
>>>
>>>
>>
>>
>> --
>> Michael S Collins
>> Twitter: @mercutioviz
>> http://www.FreeSWITCH.org <http://www.freeswitch.org/>
>> http://www.ClueCon.com <http://www.cluecon.com/>
>> http://www.OSTAG.org <http://www.ostag.org/>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.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://wiki.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
>
>

-- 
Michael S Collins
Twitter: @mercutioviz
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121226/d57c8083/attachment-0001.html 