apply-register acl is specifically designed to be used with the "domains" acl which is automatically generated by scanning the user directory and building a list using the cidr field and tokenizing the user to match the range of each acl entry. Its not really useful with normal acl's.

On Wed, Mar 12, 2014 at 8:23 AM, Florent Krieg <fkrieg@sewan.eu> wrote:

I forgot the part of sofia.c that does switch user, please find it inlined below.

Le 12/03/2014 14:03, Florent Krieg a écrit :

Hello all,

While checking and tuning our FreeSWITCH configuration, I found out that there is big difference of behaviour between the apply-inbound-acl and apply-register-acl sofia sip profile parameters.
=> in the case of 'apply-inbound-acl', requests coming from an IP present in the acl profile list will be authentified as the matching account, which is OK.
=> in the case of 'apply-register-acl', register requests coming from an IP present in the acl profile list will be authorized (which is OK), while being 'authentified' as the user specified in the SIP request. I would have imagined that register requests would be identified as the matching account as well. We end up in getting crazy registrations (devices registered as user not existing in the directory for instance), when customers' hardware are not permissive enough to allow from (user@domain) field customisation (while outgoing calls are perfectly working).

Is that behaviour wanted by the community?

I checked the source code which I reckon I am not familiar with at all, and I found that:
* apply-inbound-acl (sofia.c):

if (profile->acl_count) {                uint32_t x = 0;                int ok = 1;                char *last_acl = NULL;                const char *token = NULL;                for (x = 0; x < profile->acl_count; x++) {                        last_acl = profile->acl[x];                        if ((ok = switch_check_network_list_ip_token(network_ip, last_acl, &token))) {                                if (profile->acl_pass_context[x]) {                                        acl_context = profile->acl_pass_context[x];                                }                                break;                        }                        if (profile->acl_fail_context[x]) {                                acl_context = profile->acl_fail_context[x];                        } else {                                acl_context = NULL;                        }                }                if (ok) {                        if (token) {                                switch_set_string(acl_token, token);                        }                        if (sofia_test_pflag(profile, PFLAG_AUTH_CALLS)) {                                switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "IP %s Approved by acl \"%s[%s]\". Access Granted.\n",                                                                  network_ip, switch_str_nil(last_acl), acl_token);                                switch_set_string(sip_acl_authed_by, last_acl);                                switch_set_string(sip_acl_token, acl_token);                                is_auth = 1;                        }

[...]

if (*acl_token) {
                switch_channel_set_variable(channel, "acl_token", acl_token);
                if (strchr(acl_token, '@')) {
                        if (switch_ivr_set_user(session, acl_token) == SWITCH_STATUS_SUCCESS) {
                                switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG, "Authenticating user %s\n", acl_token);
                        } else {
                                switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "Error Authenticating user %s\n", acl_token);
                        }
                }
        }
* apply-register-acl (sofia_reg.c):

if (profile->reg_acl_count) { uint32_t x = 0; int ok = 1; char *last_acl = NULL; for (x = 0; x < profile->reg_acl_count; x++) { last_acl = profile->reg_acl[x]; if (!(ok = switch_check_network_list_ip(network_ip, last_acl))) { break; } } if (ok && !sofia_test_pflag(profile, PFLAG_BLIND_REG)) { type = REG_AUTO_REGISTER;

Is what I expect (similar behaviour in both cases) crazy to you? Or does it sound right?

In the latter case, should I open a JIRA case for somebody to push a fix?
I could try to 'fix' it myself (in case you consider it as a bug as I do) but I am not really familiar with C development as well.

Thank for your points of view!
Regards
Florent
_________________________________________________________________________
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-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
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-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬

☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH

☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+

ClueCon Weekly Development Call

☎ sip:888@conference.freeswitch.org ☎ +19193869900