On Thu, Apr 10, 2008 at 6:58 AM, Mikael A. Bjerkeland <[EMAIL PROTECTED]>
wrote:
>
> tor, 10.04.2008 kl. 13.44 +0200, skrev kokoska rokoska:
> > Hi all,
> >
> > I try to implement "continue on fail" with different actions (Forward,
> > Voicemail, InbandInfo...) based on failure type (No Answer, Busy...)and
> > come into troubles how to do :-)
> >
> > From what I know about FreeSWITCH (very few :-) I see three solutions,
> > but I do not like any of them :-)
> >
> > Pre: My dialplan si served by http server through mod_xml_curl.
> >
> > 1. After the failure use something "Asterisk like"
> > <action application="transfer" data="${originate_disposition}"/>
> > But why should I invoke transfer (new dialplan parsing, garbage in CDR)
> > for such a simple thing?
> An idea:
> You can use execute_extension which behaves similar to Asterisk's Macro.
> Transfer has a closer resemblance to Goto.
>
or you can just set hangup_after_bridge=true and put a list of bridge lines
in a row
<action application="set" data="hangup_after_bridge=true"/>
<action application="bridge" data="sofia/foo/[EMAIL PROTECTED]"/>
<action application="bridge" data="sofia/foo/[EMAIL PROTECTED]"/>
<action application="bridge" data="sofia/foo/[EMAIL PROTECTED]"/>
or you can split all the routes with a | and let originate deal with it
<action application="bridge" data="sofia/foo/[EMAIL PROTECTED]|sofia/foo/[EMAIL
PROTECTED]
|sofia/foo/[EMAIL PROTECTED]"/>
>
> >
> > 2. Use ...break="never"... and serve next extension through
> > mod_xml_curl. Bur it invokes unnecessary http request and even I ask,
> > why should I send it in parts if I know all I need at the beginning of
> > the call?
> >
> > 3. Use custom app to handle processing of failed bridge.
> > <action application="bridge" data="sofia/xxx/yyy%zzz"/>
> > <action application="whatever_lang" data="whatever_name
> > ${originate_disposition}"/>
> > But I dislike to start new process/thread (performance) and, like in
> > previous cases, why to do it i parts, if have all info at the beginnig?
> >
>
FreeSWITCH does not parse the dialplan as it's executing it parses it once
when the call is in the RING state much like a dns lookup.
When a new call comes into FS it goes to RING which looks up the desired
dialplan by name and routes the session to that dialplans hunt function.
This function has 1 chance to look at the call data and install a set of
instructions. If it does this the core will take the resulting extension
and change the session state to EXECUTE where it will execute the
instructions.
The XML dialplan uses the XML to perform this task and is actually nothing
more than an example of how FS can be used. When it parses the XML it runs
through the whole thing matching conditions etc and the resulting actions
are installed into the session and that's the end of the XML. so the
break=never thing is irrelevant.
In fact the way FS works, it's actuall the transfer option you described
that would result in a new curl request because transfer sends the call back
to ring state where it repeats the dialplan lookup process with a new
destination_number.
>
> >
> > If I look to my ideas, I'm sure I miss something important :-)
> > Could you, please, point me to right way? Or just tell me your "rating"
> > of cases above :-)
> >
>
> Please tell me how it goes and post some examples of your configs if you
> get it to work.
>
> > Thank you very much!
> >
> > Best regards,
> >
> > kokoska.rokoska
> >
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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
>
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:[EMAIL PROTECTED] <[EMAIL PROTECTED]>
GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>
iax:[EMAIL PROTECTED]/888
googletalk:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
pstn:213-799-1400
_______________________________________________
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
