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

[Anthony Minessale]

One thing you can do is set the variable when you do know it, from the
dialplan.  So it will be there in all the subsequent events.



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

> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.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
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121119/0d87c5c3/attachment-0001.html