[Freeswitch-users] mod_xml_curl - missing dialplan variable (domain of originating user for blind transfer)

[Cal Leeming [Simplicity Media Ltd]]

Last update, then I'm really going to sleep!

Apologies for the noise btw, in hindsight I should have collected all this
info and posted in one go.

I've tried enabling auth-all-packets (along with auth_calls), as I thought
maybe having authentication on REFER packets might make a difference, but
sadly it had no effect (the SIP headers show proxy-authorization in the
REFER, but nothing extra showed in mod_xml_curl)

I've managed to narrow down the circumstances in which this happens;

CORRECT:

* User receives call from gateway, blind transfer to another user (shows
correctly as variable_dialed_user/variable_dialed_domain)
* User receives call from another user, blind transfer to gateway (shows
correctly as variable_dialed_user/variable_dialed_domain)
* User receives call from another user, blind transfer to another
user (shows correctly as variable_dialed_user/variable_dialed_domain)
* User makes call to another user, blind transfer to another user (shows
correctly as variable_dialed_user/variable_dialed_domain)
* User makes call to another user, blind transfer to a gateway (shows
correctly as variable_dialed_user/variable_dialed_domain)

MISSING:

* User makes call to a gateway, blind transfer to another gateway (no clean
variables for domain)
* User makes call to a gateway, blind transfer to another user (no clean
variables for domain)

So, the problem seems to happen specifically when you blind transfer a call
that is already in progress on a gateway, where the call was originated by
a user and not a gateway.

I did a bit more looking through code, added a few switch_log_printf()
calls, and found that the following method is NOT called in those two
scenarios where these variables are missing;
mod_dptools.c: "switch_call_cause_t user_outgoing_channel"

This is about as far as I can go on this, as I just don't know enough about
C to give any more in-depth info :/

Cal

On Mon, Nov 19, 2012 at 5:52 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> Sorry, another update.. after tinkering with the SIP headers, we found
> that we're able to pass any user/host along in an INVITE, and this is
> passed onto mod_xml_curl.
>
> To fix this particular part of the problem, we enabled auth_calls and this
> gives us correct/clean variables we can trust, specifically;
>
>  u'variable_sip_auth_username': u'2000',
>  u'variable_user_name': u'2000',
>
> However, when attempting to do the blind transfer again, this variables
> are all missing.
>
> At this point I'm convinced that attempting to extract the user/domain
> from the Refer headers is probably not the right thing to do... But I'm
> still no closer to figuring out what the correct approach should be to
> expose the authenticated user/domain to mod_xml_curl.
>
> Cal
>
>
> On Mon, Nov 19, 2012 at 4:58 AM, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming at simplicitymedialtd.co.uk> wrote:
>
>> Another quick update on this before I pass out from lack of sleep..!
>>
>> Just had a look through the mod_sofia.c/h source and found the following;
>>
>> mod_sofia.c/mod_sofia.h
>> #define SOFIA_REFER_TO_VARIABLE "sip_refer_to"
>> if (!zstr(full_ref_by)) {
>> switch_channel_set_variable(t_channel, SOFIA_SIP_HEADER_PREFIX
>> "Referred-By", full_ref_by);
>> }
>> if (!zstr(full_ref_to)) {
>> switch_channel_set_variable(t_channel, SOFIA_REFER_TO_VARIABLE,
>> full_ref_to);
>> }
>> if (!zstr(full_ref_to)) {
>>  switch_channel_set_variable(t_channel, SOFIA_REFER_TO_VARIABLE,
>> full_ref_to);
>> }
>> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG,
>> "Process REFER to [%s@%s]\n", exten, (char *) refer_to->r_url->url_host);
>>
>> If the correct approach is deemed to be patching code, then I figured it
>> could be as simple as this;
>>
>> switch_channel_set_variable(t_channel, "Referred-By-User", exten);
>> switch_channel_set_variable(t_channel, "Referred-By-Domain", (char *)
>> refer_to->r_url->url_host);
>>
>> This is pretty much where my knowledge of C ends, I can (just about) read
>> and copy chunks of C code, but that's about it :)
>>
>> Cal
>>
>> On Mon, Nov 19, 2012 at 4:38 AM, Cal Leeming [Simplicity Media Ltd] <
>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>
>>> Not sure if this is relevant but thought I'd point it out.
>>>
>>> The following field seems to contain the IP of the domain we were
>>> expecting ('c1881.voiceflare.co.uk')
>>>
>>>  u'variable_sip_from_host': u'89.238.182.137',
>>>
>>> Normally, this field would contain the hostname and not the IP.
>>>
>>> Cal
>>>
>>> On Mon, Nov 19, 2012 at 4:34 AM, Cal Leeming [Simplicity Media Ltd] <
>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> In a nut shell, it appears that when attempting to perform a blind
>>>> transfer under certain conditions (explained below), mod_xml_curl does not
>>>> expose the originating domain in a clean format.
>>>>
>>>> My initial plan was to find the point where these variable were being
>>>> generated, look at what was available, then add an extra variable for the
>>>> domain and submit a patch.
>>>>
>>>> Sadly my C isn't great and I hit a brick wall, so if anyone can help
>>>> out, I will ensure the mod_xml_curl documentation is updated and/or assist
>>>> with any patching/testing required.
>>>>
>>>>  Please take the following scenario;
>>>>
>>>> * Extension 2000 calls an external number via a gateway (i.e. bridge
>>>> sofia/gateway/name/e164_number_here).
>>>> * Call connects fine, audio stays good, no disconnection problems etc.
>>>> * Call is blind transferred to another extension
>>>>
>>>> As a result, the following is determined;
>>>>
>>>> * User initiating the blind transfer is 2000
>>>> * Domain initiating the blind transfer is c1881.voiceflare.co.uk
>>>> * Destination number of the call is 447866123456
>>>> * Number to blind transfer to is 2001
>>>> * Call to mod_xml_curl is made
>>>>
>>>> It makes reference to the User in the following 'clean' variables (by
>>>> clean, I mean variables that just contain 2000 and don't require mangling
>>>> to extract the info);
>>>>
>>>>  u'Caller-ANI': u'2000',
>>>>  u'Caller-Username': u'2000',
>>>>  u'Caller-Caller-ID-Number': u'2000',
>>>>  u'Hunt-ANI': u'2000',
>>>>  u'Hunt-Caller-ID-Number': u'2000',
>>>>  u'Hunt-Username': u'2000',
>>>>  u'variable_last_sent_callee_id_number': u'2000',
>>>>  u'variable_sip_from_user': u'2000',
>>>>
>>>> It also has the User in the following unclean variables;
>>>>
>>>>  u'variable_bridge_channel': u'sofia/external/
>>>> 2000 at c1881.voiceflare.co.uk:5060',
>>>>  u'variable_sip_from_uri': u'2000 at 89.238.182.137',
>>>>  u'variable_sip_full_from': u'"foxx" <sip:2000 at 89.238.182.137
>>>> >;tag=XryjFQp3rB2NF',
>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>> sip:2000 at c1881.voiceflare.co.uk:5060>',
>>>>
>>>> However, it only references the domain in the following unclean
>>>> variables;
>>>>
>>>>  u'variable_bridge_channel': u'sofia/external/
>>>> 2000 at c1881.voiceflare.co.uk:5060',
>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>> sip:2000 at c1881.voiceflare.co.uk:5060>',
>>>>  u'variable_sip_refer_to': u'<sip:2001 at c1881.voiceflare.co.uk:5060>',
>>>>
>>>> Lets say that we want to determine the user/domain that has initiated
>>>> this transfer, doing so would mean mangling with one of those above
>>>> variables, which seems a bit dirty (plus it is not clear which is the
>>>> correct one to use).
>>>>
>>>> I have attached the SIP trace of the entire blind transfer event, and
>>>> the full mod_xml_curl request being sent.
>>>>
>>>> If anyone could answer the following, it'd be much appreciated;
>>>>
>>>> * Should there be an improvement patch that exposes the domain of the
>>>> user that originated the blind transfer?
>>>> * Are there better/alternative ways to extracting the domain of the
>>>> user that originated the blind transfer?
>>>>
>>>> Many thanks
>>>>
>>>> Cal
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121119/63f4d46f/attachment.html