[Freeswitch-users] IVR dialplan inheritance

[Steven Ayre]

>
> 3) handle the +37950290088 call before the ivr_route extension so it
> doesn't reach that one.


That should have read 37950280022 (destination number) rather than 37950290088
(caller id)

On 14 May 2015 at 17:10, Steven Ayre <steveayre at gmail.com> wrote:

> Dialplan: sofia/external/+37950290088 at fs parsing [public->ivr_route]
> continue=false
> Dialplan: sofia/external/+37950290088 at fs Absolute Condition [ivr_route]
> Dialplan: sofia/external/+37950290088 at fs Action answer()
> Dialplan: sofia/external/+37950290088 at fs Action sleep(2000)
> Dialplan: sofia/external/+37950290088 at fs Action ivr(1)
>
> You have an absolute condition, so this will match every call that reaches
> that part of the dialplan context. That includes after the transfer.
>
> You need to either 1) change your condition so it only matches the calls
> you want to go to the IVR menu, 2) transfer to a different context from the
> menu or 3) handle the +37950290088 call before the ivr_route extension so
> it doesn't reach that one.
>
> On 14 May 2015 at 10:07, Ben Hood <0x6e6562 at gmail.com> wrote:
>
>> Hi all,
>>
>> I was wondering under what circumstances an IVR menu would loop back
>> on itself when a transfer is triggered by user input.
>>
>> I have the following menu:
>>
>> <document type="freeswitch/xml">
>> <section name="configuration">
>> <configuration name="ivr.conf">
>> <menus>
>> <include>
>> <menu name="1"
>> greet-long="http_cache://http://$${user}:$${password}@
>> $${url}/audio/76568832.wav"
>> invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
>> exit-sound="voicemail/vm-goodbye.wav"
>> confirm-macro=""
>> confirm-key=""
>> confirm-attempts="3"
>> timeout="10000"
>> inter-digit-timeout="2000"
>> max-failures="3"
>> max-timeouts="3"
>> digit-len="1">
>>  <entry action="menu-exec-app" digits="3" param="transfer +37950280022
>> XML public"/>
>> </menu>
>> </include>
>> </menus>
>> </configuration>
>> </section>
>> </document>
>>
>> When the user dials 3, the following output in the log occurs:
>>
>> 2015-05-14 10:43:00.861297 [NOTICE] switch_ivr.c:1861 Transfer
>> sofia/external/+37950290088 at fs to XML[+37950280022 at public]
>> ...
>> 2015-05-14 10:43:00.861297 [INFO] mod_dialplan_xml.c:635 Processing
>> +37950290088 <+37950290088>->+37950280022 in context public
>>
>> So at this point in time, I would expect the dialplan that matches
>> +37950280022 to get executed.
>>
>> However, what appears to happen is that the dialplan that originally
>> invoked the ivr application is executed again:
>>
>> Dialplan: sofia/external/+37950290088 at fs parsing [public->ivr_route]
>> continue=false
>> Dialplan: sofia/external/+37950290088 at fs Absolute Condition [ivr_route]
>> Dialplan: sofia/external/+37950290088 at fs Action answer()
>> Dialplan: sofia/external/+37950290088 at fs Action sleep(2000)
>> Dialplan: sofia/external/+37950290088 at fs Action ivr(1)
>>
>> This creates a loop.
>>
>> This is the original dialplan that invokes the ivr menu:
>>
>> <document type="freeswitch/xml">
>> <section name="dialplan">
>> <context name="public">
>> <extension name="ivr_route">
>> <condition>
>> <action application="answer"/>
>> <action application="sleep" data="2000"/>
>> <action application="ivr" data="1"/>
>> </condition>
>> </extension>
>> </context>
>> </section>
>> </document>
>>
>> Is there potentially something in my menu definition that is causing
>> the original dialplan to executed, as opposed to the dialplan
>> specified by the transfer application?
>>
>> Many thanks in advance,
>>
>> Ben
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150514/34e20696/attachment.html