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@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@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@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@c1881.voiceflare.co.uk:5060', u'variable_sip_from_uri': u'2000@89.238.182.137', u'variable_sip_full_from': u'"foxx" <sip:2000@89.238.182.137

...

;tag=XryjFQp3rB2NF', u'variable_sip_h_Referred-By': u'"foxx" < sip:2000@c1881.voiceflare.co.uk:5060>',

However, it only references the domain in the following unclean variables;

u'variable_bridge_channel': u'sofia/external/ 2000@c1881.voiceflare.co.uk:5060', u'variable_sip_h_Referred-By': u'"foxx" < sip:2000@c1881.voiceflare.co.uk:5060>', u'variable_sip_refer_to': u'<sip:2001@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

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@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@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@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@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@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@c1881.voiceflare.co.uk:5060', u'variable_sip_from_uri': u'2000@89.238.182.137', u'variable_sip_full_from': u'"foxx" <sip:2000@89.238.182.137

...

;tag=XryjFQp3rB2NF', u'variable_sip_h_Referred-By': u'"foxx" < sip:2000@c1881.voiceflare.co.uk:5060>',

However, it only references the domain in the following unclean variables;

u'variable_bridge_channel': u'sofia/external/ 2000@c1881.voiceflare.co.uk:5060', u'variable_sip_h_Referred-By': u'"foxx" < sip:2000@c1881.voiceflare.co.uk:5060>', u'variable_sip_refer_to': u'<sip:2001@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@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900

I have started to move some of this information into the wiki.

However, my previous comments about
forcing sip_auth_realm/sip_auth_username are generally considered unsafe
from a security point of view.

If you force those variables, under some circumstances a blind transferred
call from an external gateway could later on be considered an authorized
internal user and lead to undesired behaviour.

Forcing sip_invite_domain however is acceptable, as some request context
will lose this information during a blind transfer or bridge.

I am currently building up a spreadsheet of different call scenarios, along
with the request variables for each one, so it is easy to see how the
variables change depending on what event is happening.

Cal

On Tue, Nov 20, 2012 at 1:21 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming@simplicitymedialtd.co.uk> wrote:

> Hi Anthony,
>
> Thanks for the reply, yeah I spent some time looking at alternative ways
> and came up with one that seems to get the job done
>
> I am convinced now that there is no bug as such - but one thing that is
> absolutely clear, is that mod_xml_curl is in desperate need of
> normalization.. even if it was fully documented, some of the variants don't
> make logical sense. However, the information is there, and as long as you
> do the correct conditional checks, then it will work flawlessly.
>
> To make the authenticated domain stick when passing through to a gateway,
> we use the following;
>
> <action application="bridge"
> data="{sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}sofia/gateway/{{
> dst.gateway.name
> }}/{{dst.gateway.fs_dial_prefix}}{{dst.dst_number_e164}}"/>
>
> The most important part of the above being;
>
> {sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}
>
> However, this alone doesn't deal with the fact that you have to look in
> different places for the correct variables depending on what the current
> call context is.
>
> To a certain extent, your own business logic will also determine which
> variables should be used, and a combination of conditional checks may need
> to be used in order to figure out which variable you should be using in the
> first place lol.
>
> Here are the patterns we have found so far - this is just an information
> dump for now, and later down the road I will update the mod_xml_curl
> documentation.
>
> # Ensure that variable_sip_auth_username / variable_sip_auth_realm
> #
> # If Call-Direction is inbound, then;
> # src_user = variable_sip_auth_username
> # src_domain = variable_sip_auth_realm
> # dst_user = variable_sip_to_user
> #
> # If Call-Direction is outbound, then;
> # originate_user = variable_sip_auth_username
> # originate_domain = variable_sip_auth_realm
> # src_user = variable_sip_to_user
> # src_domain = variable_sip_to_host
> # dst_user = Caller-Destination-Number
>
> * gateway to gateway (442476100401 > 442476100402)
> * domain to gateway - blind xfer to gateway (2000 > 442476100401
> > 442476100402)
> * domain to gateway - blind xfer to domain (2000 > 442476100401 > 2002)
> * domain to gateway (2000 > 442476100401)
> * domain to domain (2000 > 2001)
>
> ----
>
> # Check if variable_sip_to_host is present and known gateway
> #
> # If variable_dialed_user and variable_dialed_domain are present;
> # originate_user = variable_dialed_user
> # originate_domain = variable_dialed_domain
> # src_user = variable_sip_from_user
> # src_domain = variable_sip_to_host
> # dst_user = Caller-Destination-Number
> #
> # If not present;
> # src_user = variable_sip_from_user
> # src_domain = variable_sip_to_host
> # dst_user = variable_sip_to_user
>
> * gateway to domain (442476100401 > 2002)
> * gateway to domain - blind xfer to gateway (442476100401 > 2000
> > 442476100402)
> * gateway to domain - blind xfer to domain (442476100401 > 2000 > 2002)
>
> ----
>
> # check for variable_dialed_domain
> # If match;
> # src_user = variable_dialed_user
> # src_domain  = variable_dialed_domain
> # dst_user = Caller-Destination-Number
>
> * domain to domain to gateway (2000 > 2001 > 442476100402)
>
>
> On Tue, Nov 20, 2012 at 2:55 AM, Anthony Minessale <
> anthony.minessale@gmail.com> wrote:
>
>> 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@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@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@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@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@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@c1881.voiceflare.co.uk:5060',
>>>>>>>  u'variable_sip_from_uri': u'2000@89.238.182.137',
>>>>>>>  u'variable_sip_full_from': u'"foxx" <sip:2000@89.238.182.137
>>>>>>> >;tag=XryjFQp3rB2NF',
>>>>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>> sip:2000@c1881.voiceflare.co.uk:5060>',
>>>>>>>
>>>>>>> However, it only references the domain in the following unclean
>>>>>>> variables;
>>>>>>>
>>>>>>>  u'variable_bridge_channel': u'sofia/external/
>>>>>>> 2000@c1881.voiceflare.co.uk:5060',
>>>>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>> sip:2000@c1881.voiceflare.co.uk:5060>',
>>>>>>>  u'variable_sip_refer_to': u'<sip:2001@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@freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>> http://www.cudatel.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.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
>>>
>>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale@hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888@conference.freeswitch.org
>> googletalk:conf+888@conference.freeswitch.org
>> pstn:+19193869900
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting@freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> http://www.cudatel.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.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
>>
>>
>

>From what I can tell - that's not entirely correct from a security stand
point.

Let's say a call comes in from an external gateway (DDI 442476100401), it's
routed to user 2001.

If you do 'set_user' then you'd be effectively saying that Leg A of the
call is an authorized user - is this correct?

If so - this could have all sorts of implications when performing
sanity/security checks on later events.

Please let me know if I'm wrong, as I haven't used 'set_user' much.

Cal

On Sun, Dec 30, 2012 at 7:38 PM, Dave R. Kompel <drk@drkngs.net> wrote:

> **
>  Since this is for use in external generated XML, and for the most part
> it should be code that is generating it, the easiest way to handle calls
> from gateways, is to back them with users in the directory. When A calll is
> from a gateway, simply do a set_user in your dialplan, and then a transfer
> back to the number dialed in the context ${user_context}, which will be set
> after you do the set_user.
>
> This way you don't have to do anything special for calls that come from a
> gateway, transfers and other things just work right.
>
> --Dave
>
>
>  ------------------------------
> *From:* Cal Leeming [Simplicity Media Ltd] [mailto:
> cal.leeming@simplicitymedialtd.co.uk]
> *To:* FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]
> *Sent:* Sun, 30 Dec 2012 10:04:57 -0800
> *Subject:* Re: [Freeswitch-users] mod_xml_curl - missing dialplan
> variable (domain of originating user for blind transfer)
>
>
> I have started to move some of this information into the wiki.
>
> However, my previous comments about
> forcing sip_auth_realm/sip_auth_username are generally considered unsafe
> from a security point of view.
>
> If you force those variables, under some circumstances a blind transferred
> call from an external gateway could later on be considered an authorized
> internal user and lead to undesired behaviour.
>
> Forcing sip_invite_domain however is acceptable, as some request context
> will lose this information during a blind transfer or bridge.
>
> I am currently building up a spreadsheet of different call scenarios,
> along with the request variables for each one, so it is easy to see how the
> variables change depending on what event is happening.
>
> Cal
>
> On Tue, Nov 20, 2012 at 1:21 PM, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming@simplicitymedialtd.co.uk> wrote:
>
>> Hi Anthony,
>>
>> Thanks for the reply, yeah I spent some time looking at alternative ways
>> and came up with one that seems to get the job done
>>
>> I am convinced now that there is no bug as such - but one thing that is
>> absolutely clear, is that mod_xml_curl is in desperate need of
>> normalization.. even if it was fully documented, some of the variants don't
>> make logical sense. However, the information is there, and as long as you
>> do the correct conditional checks, then it will work flawlessly.
>>
>> To make the authenticated domain stick when passing through to a gateway,
>> we use the following;
>>
>> <action application="bridge"
>> data="{sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}sofia/gateway/{{
>> dst.gateway.name
>> }}/{{dst.gateway.fs_dial_prefix}}{{dst.dst_number_e164}}"/>
>>
>> The most important part of the above being;
>>
>> {sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}
>>
>> However, this alone doesn't deal with the fact that you have to look in
>> different places for the correct variables depending on what the current
>> call context is.
>>
>> To a certain extent, your own business logic will also determine which
>> variables should be used, and a combination of conditional checks may need
>> to be used in order to figure out which variable you should be using in the
>> first place lol.
>>
>> Here are the patterns we have found so far - this is just an information
>> dump for now, and later down the road I will update the mod_xml_curl
>> documentation.
>>
>> # Ensure that variable_sip_auth_username / variable_sip_auth_realm
>> #
>> # If Call-Direction is inbound, then;
>> # src_user = variable_sip_auth_username
>> # src_domain = variable_sip_auth_realm
>> # dst_user = variable_sip_to_user
>> #
>> # If Call-Direction is outbound, then;
>> # originate_user = variable_sip_auth_username
>> # originate_domain = variable_sip_auth_realm
>> # src_user = variable_sip_to_user
>> # src_domain = variable_sip_to_host
>> # dst_user = Caller-Destination-Number
>>
>> * gateway to gateway (442476100401 > 442476100402)
>> * domain to gateway - blind xfer to gateway (2000 > 442476100401
>> > 442476100402)
>> * domain to gateway - blind xfer to domain (2000 > 442476100401 > 2002)
>> * domain to gateway (2000 > 442476100401)
>> * domain to domain (2000 > 2001)
>>
>> ----
>>
>> # Check if variable_sip_to_host is present and known gateway
>> #
>> # If variable_dialed_user and variable_dialed_domain are present;
>> # originate_user = variable_dialed_user
>> # originate_domain = variable_dialed_domain
>> # src_user = variable_sip_from_user
>> # src_domain = variable_sip_to_host
>> # dst_user = Caller-Destination-Number
>> #
>> # If not present;
>> # src_user = variable_sip_from_user
>> # src_domain = variable_sip_to_host
>> # dst_user = variable_sip_to_user
>>
>>  * gateway to domain (442476100401 > 2002)
>> * gateway to domain - blind xfer to gateway (442476100401 > 2000
>> > 442476100402)
>> * gateway to domain - blind xfer to domain (442476100401 > 2000 > 2002)
>>
>> ----
>>
>> # check for variable_dialed_domain
>> # If match;
>> # src_user = variable_dialed_user
>> # src_domain  = variable_dialed_domain
>> # dst_user = Caller-Destination-Number
>>
>>  * domain to domain to gateway (2000 > 2001 > 442476100402)
>>
>>
>> On Tue, Nov 20, 2012 at 2:55 AM, Anthony Minessale <
>> anthony.minessale@gmail.com> wrote:
>>
>>> 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@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@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@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@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@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@c1881.voiceflare.co.uk:5060',
>>>>>>>>   u'variable_sip_from_uri': u'2000@89.238.182.137',
>>>>>>>>  u'variable_sip_full_from': u'"foxx" <sip:2000@89.238.182.137
>>>>>>>> >;tag=XryjFQp3rB2NF',
>>>>>>>>   u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>>> sip:2000@c1881.voiceflare.co.uk:5060>',
>>>>>>>>
>>>>>>>> However, it only references the domain in the following unclean
>>>>>>>> variables;
>>>>>>>>
>>>>>>>>  u'variable_bridge_channel': u'sofia/external/
>>>>>>>> 2000@c1881.voiceflare.co.uk:5060',
>>>>>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>>> sip:2000@c1881.voiceflare.co.uk:5060>',
>>>>>>>>  u'variable_sip_refer_to': u'<sip:2001@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@freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>>> http://www.cudatel.com
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://wiki.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
>>>>
>>>>
>>>
>>>
>>> --
>>> Anthony Minessale II
>>>
>>> FreeSWITCH http://www.freeswitch.org/
>>> ClueCon http://www.cluecon.com/
>>> Twitter: http://twitter.com/FreeSWITCH_wire
>>>
>>> AIM: anthm
>>> MSN:anthony_minessale@hotmail.com
>>> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888@conference.freeswitch.org
>>> googletalk:conf+888@conference.freeswitch.org
>>> pstn:+19193869900
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting@freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>> http://www.cudatel.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.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
>>>
>>>
>>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.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
>
>

Sorry, I might have misunderstood but that doesn't clarify the potential
security flaw of using set_user.

I agree that the call needs correct context, but forcing a call from a
gateway to use the context of the user they are calling doesn't sound like
the right thing to do.

Am I missing something here??

Cal

On Sun, Dec 30, 2012 at 11:27 PM, Dave R. Kompel <drk@drkngs.net> wrote:

> **
> No, you want to have a gateway user that you use that has the right
> context, so they can't dial out on their own, but the user CAN transfer
> them to something external if you want.
>
> --Dave
>
>  ------------------------------
> *From:* Cal Leeming [Simplicity Media Ltd] [mailto:
> cal.leeming@simplicitymedialtd.co.uk]
> *To:* FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]
> *Sent:* Sun, 30 Dec 2012 12:12:55 -0800
>
> *Subject:* Re: [Freeswitch-users] mod_xml_curl - missing dialplan
> variable (domain of originating user for blind transfer)
>
> >From what I can tell - that's not entirely correct from a security stand
> point.
>
> Let's say a call comes in from an external gateway (DDI 442476100401),
> it's routed to user 2001.
>
> If you do 'set_user' then you'd be effectively saying that Leg A of the
> call is an authorized user - is this correct?
>
> If so - this could have all sorts of implications when performing
> sanity/security checks on later events.
>
> Please let me know if I'm wrong, as I haven't used 'set_user' much.
>
> Cal
>
> On Sun, Dec 30, 2012 at 7:38 PM, Dave R. Kompel <drk@drkngs.net> wrote:
>
>> **
>>  Since this is for use in external generated XML, and for the most part
>> it should be code that is generating it, the easiest way to handle calls
>> from gateways, is to back them with users in the directory. When A calll is
>> from a gateway, simply do a set_user in your dialplan, and then a transfer
>> back to the number dialed in the context ${user_context}, which will be set
>> after you do the set_user.
>>
>> This way you don't have to do anything special for calls that come from a
>> gateway, transfers and other things just work right.
>>
>> --Dave
>>
>>
>>  ------------------------------
>> *From:* Cal Leeming [Simplicity Media Ltd] [mailto:
>> cal.leeming@simplicitymedialtd.co.uk]
>> *To:* FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org
>> ]
>> *Sent:* Sun, 30 Dec 2012 10:04:57 -0800
>> *Subject:* Re: [Freeswitch-users] mod_xml_curl - missing dialplan
>> variable (domain of originating user for blind transfer)
>>
>>
>> I have started to move some of this information into the wiki.
>>
>> However, my previous comments about
>> forcing sip_auth_realm/sip_auth_username are generally considered unsafe
>> from a security point of view.
>>
>> If you force those variables, under some circumstances a blind
>> transferred call from an external gateway could later on be considered an
>> authorized internal user and lead to undesired behaviour.
>>
>> Forcing sip_invite_domain however is acceptable, as some request context
>> will lose this information during a blind transfer or bridge.
>>
>> I am currently building up a spreadsheet of different call scenarios,
>> along with the request variables for each one, so it is easy to see how the
>> variables change depending on what event is happening.
>>
>> Cal
>>
>> On Tue, Nov 20, 2012 at 1:21 PM, Cal Leeming [Simplicity Media Ltd] <
>> cal.leeming@simplicitymedialtd.co.uk> wrote:
>>
>>> Hi Anthony,
>>>
>>> Thanks for the reply, yeah I spent some time looking at alternative ways
>>> and came up with one that seems to get the job done
>>>
>>> I am convinced now that there is no bug as such - but one thing that is
>>> absolutely clear, is that mod_xml_curl is in desperate need of
>>> normalization.. even if it was fully documented, some of the variants don't
>>> make logical sense. However, the information is there, and as long as you
>>> do the correct conditional checks, then it will work flawlessly.
>>>
>>> To make the authenticated domain stick when passing through to a
>>> gateway, we use the following;
>>>
>>> <action application="bridge"
>>> data="{sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}sofia/gateway/{{
>>> dst.gateway.name
>>> }}/{{dst.gateway.fs_dial_prefix}}{{dst.dst_number_e164}}"/>
>>>
>>> The most important part of the above being;
>>>
>>> {sip_auth_realm=${sip_auth_realm}}{sip_auth_username=${sip_auth_username}}{sip_invite_domain=${sip_from_host}}
>>>
>>> However, this alone doesn't deal with the fact that you have to look in
>>> different places for the correct variables depending on what the current
>>> call context is.
>>>
>>> To a certain extent, your own business logic will also determine which
>>> variables should be used, and a combination of conditional checks may need
>>> to be used in order to figure out which variable you should be using in the
>>> first place lol.
>>>
>>> Here are the patterns we have found so far - this is just an information
>>> dump for now, and later down the road I will update the mod_xml_curl
>>> documentation.
>>>
>>> # Ensure that variable_sip_auth_username / variable_sip_auth_realm
>>> #
>>> # If Call-Direction is inbound, then;
>>> # src_user = variable_sip_auth_username
>>> # src_domain = variable_sip_auth_realm
>>> # dst_user = variable_sip_to_user
>>> #
>>> # If Call-Direction is outbound, then;
>>> # originate_user = variable_sip_auth_username
>>> # originate_domain = variable_sip_auth_realm
>>> # src_user = variable_sip_to_user
>>> # src_domain = variable_sip_to_host
>>> # dst_user = Caller-Destination-Number
>>>
>>> * gateway to gateway (442476100401 > 442476100402)
>>> * domain to gateway - blind xfer to gateway (2000 > 442476100401
>>> > 442476100402)
>>> * domain to gateway - blind xfer to domain (2000 > 442476100401 > 2002)
>>> * domain to gateway (2000 > 442476100401)
>>> * domain to domain (2000 > 2001)
>>>
>>> ----
>>>
>>> # Check if variable_sip_to_host is present and known gateway
>>> #
>>> # If variable_dialed_user and variable_dialed_domain are present;
>>> # originate_user = variable_dialed_user
>>> # originate_domain = variable_dialed_domain
>>> # src_user = variable_sip_from_user
>>> # src_domain = variable_sip_to_host
>>> # dst_user = Caller-Destination-Number
>>> #
>>> # If not present;
>>> # src_user = variable_sip_from_user
>>> # src_domain = variable_sip_to_host
>>> # dst_user = variable_sip_to_user
>>>
>>>  * gateway to domain (442476100401 > 2002)
>>> * gateway to domain - blind xfer to gateway (442476100401 > 2000
>>> > 442476100402)
>>> * gateway to domain - blind xfer to domain (442476100401 > 2000 > 2002)
>>>
>>> ----
>>>
>>> # check for variable_dialed_domain
>>> # If match;
>>> # src_user = variable_dialed_user
>>> # src_domain  = variable_dialed_domain
>>> # dst_user = Caller-Destination-Number
>>>
>>>  * domain to domain to gateway (2000 > 2001 > 442476100402)
>>>
>>>
>>> On Tue, Nov 20, 2012 at 2:55 AM, Anthony Minessale <
>>> anthony.minessale@gmail.com> wrote:
>>>
>>>> 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@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@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@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@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@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@c1881.voiceflare.co.uk:5060',
>>>>>>>>>   u'variable_sip_from_uri': u'2000@89.238.182.137',
>>>>>>>>>  u'variable_sip_full_from': u'"foxx" <sip:2000@89.238.182.137
>>>>>>>>> >;tag=XryjFQp3rB2NF',
>>>>>>>>>   u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>>>> sip:2000@c1881.voiceflare.co.uk:5060>',
>>>>>>>>>
>>>>>>>>> However, it only references the domain in the following unclean
>>>>>>>>> variables;
>>>>>>>>>
>>>>>>>>>  u'variable_bridge_channel': u'sofia/external/
>>>>>>>>> 2000@c1881.voiceflare.co.uk:5060',
>>>>>>>>>  u'variable_sip_h_Referred-By': u'"foxx" <
>>>>>>>>> sip:2000@c1881.voiceflare.co.uk:5060>',
>>>>>>>>>  u'variable_sip_refer_to': u'<sip:2001@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@freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>>
>>>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>>>> http://www.cudatel.com
>>>>>
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Anthony Minessale II
>>>>
>>>> FreeSWITCH http://www.freeswitch.org/
>>>> ClueCon http://www.cluecon.com/
>>>> Twitter: http://twitter.com/FreeSWITCH_wire
>>>>
>>>> AIM: anthm
>>>> MSN:anthony_minessale@hotmail.com
>>>> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888@conference.freeswitch.org
>>>> googletalk:conf+888@conference.freeswitch.org
>>>> pstn:+19193869900
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting@freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>>> http://www.cudatel.com
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://wiki.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
>>>>
>>>>
>>>
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting@freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> http://www.cudatel.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.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
>>
>>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.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
>
>