[Freeswitch-dev] Help with dial plan
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 2) After this, the call should be tried through a list of carriers. If 1 carrier 200 OKs, stop processing. 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
This is a good topic. Territory that I'm slightly less familiar with, though. I know that it goes against the grain for one module to depend on another module, but can we not give as much access as possible to sofia from spidermonkey? Kind of like Teletone? Or, what's available for that? -m On Tue, 27 Mar 2007, 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
2) After this, the call should be tried through a list of carriers. If 1 carrier 200 OKs, stop processing.
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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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..
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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@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@ivr.server.com) exten => 1231,3,Dial(SIP/${EXTEN}@pstngw.server.com) exten => 1231,4,Dial(SIP/prompt2@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@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@carrier1.com" /> <action application="bridge" data="sofia/local_profile/$1@carrier2.com" /> <action application="bridge" data="sofia/local_profile/$1@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
participants (3)
-
Brian West
-
Daniel Corbe
-
Matt Klein