[Freeswitch-dev] Help with dial plan

[Daniel Corbe]

Brian,

See my comments in-line below.  Thank you for your assistance.  I
realize that you guys are trying to get the code base ready in time
for Cluecon and I appriciate you taking the time to answer a user
question -- especially this early in the development process.

On 3/27/07, Brian West <brian.west at mac.com> wrote:
>
> On Mar 27, 2007, at 8:11 PM, Daniel Corbe wrote:
>
> > http://rafb.net/p/2mEe4P69.html
> >
> > I was wondering if its possible to get FreeSWITCH to act in the
> > following scenario:
> >
> > 1) Route a call to an IVR to play a message file...  The IVR will 200
> > OK the call, play its prompt, then send a BYE
>
> Wouldn't this end the call? You can't send a BYE then expect the call
> to continue processing.  We say bye its gone.. poof.. finito..

If one leg of a call disappears for any reason, you shouldn't assume
its safe to tear down the other call leg.  Certainly true in this
case.  It makes pre-paid scenarios where I need to contact an IVR
server for whatever reason much harder to implement with FS.

Here's a summary if what I'm trying to do:

A) Connect the call to an IVR server, to play a prompt.  That's it.
The prompt in this case happens to be informational in nature, so we
don't do much processing.

B) Route the call to the PSTN.

C) Possibly route it back to the IVR server to do something else (such
as play balances back, etc)

I've played with various methods of implementing A) but the only thing
that seems to work reliably across all UAs is to 200 OK the 2nd call
leg and then BYE it when we're done.

Here's why:

Some UAs will refuse to negotiate telephone-event in the SDP when the
dialog state is "EARLY" (IE a dialog is created with a 183) which
means that no DTMF will traverse the call.

Our IVR systems used to behave like this:

1) Send a 183 with SDP
2) Play your prompts
3) Tear down the call and send a 487 back towards the UA

This made route-on-fail scenarios possible; however this broke certain
UAs due to the reason described above.

We can do this with Asterisk today by implementing multiple Dial()
commands in our dialplan like so:

exten => 1231,1,Answer() <-- This causes Asterisk to 200 OK the call
exten => 1231,2,Dial(SIP/prompt1 at ivr.server.com)
exten => 1231,3,Dial(SIP/${EXTEN}@pstngw.server.com)
exten => 1231,4,Dial(SIP/prompt2 at ivr.server.com)
exten => 1231,5,Hangup()

I would think that the following dialplan would accomplish my goal:

<context name="default">
        <extension name="globals" continue="true">
                <condition>
                        <action application="set" data="continue_on_fail=true"/>
                </condition>
        </extension>
        <extension name="ivr" continue=true>
                <condition field="destination_number" expression="^1(.+)$">
                        <action application="set"
data="hangup_after_bridge=false"/>
                        <action application="bridge"
data="sofia/local_profile/1$1 at 127.0.0.1:5061" />
                </condition>
        </extension>
        <extension name="ld_carrier" continue=false>
                <condition field="destination_number" expression="^1(.+)$">
                        <action application="set"
data="hangup_after_bridge=true"/>
                        <action application="bridge"
data="sofia/local_profile/$1 at carrier1.com" />
                        <action application="bridge"
data="sofia/local_profile/$1 at carrier2.com" />
                        <action application="bridge"
data="sofia/local_profile/$1 at carrier3.com" />
                </condition>
        </extension>
</context>

>
> >
> > 2) After this, the call should be tried through a list of carriers.
> > If 1 carrier 200 OKs, stop processing.
>
> Easy to do.. either in order or all at once.
>
> >
> > I've implemented a dial plan which I thought would behave in this way;
> > however the second <extension> block is NEVER tried on the call.
> >
> > Please see the above link for details.
> >
> > Thanks.
> > -Daniel
> >
> > _______________________________________________
> > Freeswitch-dev mailing list
> > Freeswitch-dev at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > http://www.freeswitch.org
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
>