[Freeswitch-dev] Difference of behaviour between apply-acl profile parameters

Florent Krieg fkrieg at sewan.eu
Wed Mar 12 16:03:20 MSK 2014


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 at 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;
                             }

* 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20140312/83e95d3b/attachment-0001.html 


Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-dev mailing list