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