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@fs to XML[+37950280022@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@fs parsing [public->ivr_route] continue=false Dialplan: sofia/external/+37950290088@fs Absolute Condition [ivr_route] Dialplan: sofia/external/+37950290088@fs Action answer() Dialplan: sofia/external/+37950290088@fs Action sleep(2000) Dialplan: sofia/external/+37950290088@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
Dialplan: sofia/external/+37950290088@fs parsing [public->ivr_route] continue=false Dialplan: sofia/external/+37950290088@fs Absolute Condition [ivr_route] Dialplan: sofia/external/+37950290088@fs Action answer() Dialplan: sofia/external/+37950290088@fs Action sleep(2000) Dialplan: sofia/external/+37950290088@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@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@fs to XML[+37950280022@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@fs parsing [public->ivr_route] continue=false Dialplan: sofia/external/+37950290088@fs Absolute Condition [ivr_route] Dialplan: sofia/external/+37950290088@fs Action answer() Dialplan: sofia/external/+37950290088@fs Action sleep(2000) Dialplan: sofia/external/+37950290088@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@gmail.com> wrote:
Dialplan: sofia/external/+37950290088@fs parsing [public->ivr_route] continue=false Dialplan: sofia/external/+37950290088@fs Absolute Condition [ivr_route] Dialplan: sofia/external/+37950290088@fs Action answer() Dialplan: sofia/external/+37950290088@fs Action sleep(2000) Dialplan: sofia/external/+37950290088@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@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@fs to XML[+37950280022@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@fs parsing [public->ivr_route] continue=false Dialplan: sofia/external/+37950290088@fs Absolute Condition [ivr_route] Dialplan: sofia/external/+37950290088@fs Action answer() Dialplan: sofia/external/+37950290088@fs Action sleep(2000) Dialplan: sofia/external/+37950290088@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Steven, On Thu, May 14, 2015 at 5:12 PM, Steven Ayre <steveayre@gmail.com> wrote:
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)
Many thanks for taking the time to look into this issue - much appreciated. I've tried out your suggestions, but they didn't resolve the issue - but it turns out that there was a shortcoming in my knowledge of the way mod_xml_curl works and now that I've fixed that, my problem has been solved. What I discovered is the server processing my mod_xml_curl dialplan requests was matching the destination using the variable_sip_req_user parameter. This is fine for the initial inbound SIP transaction - the server returns the appropriate dialplan. For example, in this instance, when variable_sip_req_user is set to +37950290088, the server returns: <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> Once consumed by Freeswitch, this correctly triggers the subsequent loading an IVR menu definition with the option: <entry action="menu-exec-app" digits="3" param="transfer +37950280022 XML public"/> So far so good. So this is where my own misunderstanding started. I had assumed that the next mod_xml_curl request would populate the variable_sip_req_user parameter with +37950280022, i.e. the transfer destination. It turns out that it does not, rather variable_sip_req_user remains set to +37950290088 (which is the original destination) and instead the variable Hunt-Destination-Number is set to the transfer target, i.e. +37950280022. So the fix for this issue is for the mod_xml_curl server to match dialplan requests based on Hunt-Destination-Number rather than variable_sip_req_user. I've tried this out and it seems to work. Taking a step back to think about the mechanics a bit more, this delineation between variable_sip_req_user and Hunt-Destination-Number kind of makes sense: variable_sip_req_user can be regarded as the SIP header that was received on the original INVITE, whereas the Hunt-Destination-Number is the result of routing logic applied to the call after it has entered the dialplan context. In order words, variable_sip_req_user is what was received from the wire and Hunt-Destination-Number is a product of applying business rules to the call event. That said, this is only a lay person's explanation of what is going on - feel free to correct me if I'm seeing this incorrectly. Thanks for your help. Cheers, Ben
participants (2)
-
Ben Hood
-
Steven Ayre