[Freeswitch-users] IVR dialplan inheritance

[Ben Hood]

Hi Steven,

On Thu, May 14, 2015 at 5:12 PM, Steven Ayre <steveayre at 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