[Freeswitch-dev] Difference of behaviour between apply-acl profile parameters
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; } * 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
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
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.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-dev mailing listFreeSWITCH-dev@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswi...
_________________________________________________________________________ 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+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
Hello Anthony, Actually we only use the domains acl (I am not even sure what is 'real acl', we only use it in correlaton with cidr users' fields), automatically generated by scanning the user directory (we are in a multi-homed environment). Here is an example (taken out from the logs): switch_utils.c:324 Adding XXX.XXX.XXX.XXX/32 (allow) [account@test] to list domains With 'apply-inbound-acl=domains' and 'apply-register-acl=domains', when XXX.XXX.XXX.XXX tries to register with a random login@domain (eg: alice@alice, account which doesn't exist at all, assuming we only have 'account@test') to our platform, it goes OK. If we do a 'sofia_contact alice@alice', it returns the register from the db. Now: * if we start a call, it will be authentified as 'account@test' (which is OK) * if we receive a call, we won't be able to get the contact for 'account@test' because the record in db is (to_user=)alice and (reg_host=)alice So in the last case we have to do static routing. We want to avoid it as much as possible. I am not sure whether I am clear... Regards, Florent Le 12/03/2014 15:42, Anthony Minessale a écrit :
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://irc.freenode.net> #freeswitch ? _http://freeswitch.org/g+_
ClueCon Weekly Development Call ? sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> ? +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-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, all, I wrote a fix this afternoon based on a git master pull (which compiles and works like a charm after some tests). As I haven't done C programming in ages hence I'd be very grateful if one of you could tell me if the patch is very unstable/could cause a lot of troubles, and so on. Here it is: [user@vm ~]# diff /root/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h /root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h 952c952 < uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, --- > uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, 955,956c955 < uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char *sw_acl_token); < #define sofia_reg_handle_register(_nua_, _profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_, _sofia_private_p_, _user_xml_) sofia_reg_handle_register_sw(_nua_, _profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_, _sofia_private_p_, _user_xml_, NULL) --- > uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml); [user@vm ~]# diff /root/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c /root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c 1119c1119 < uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, --- > uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, 1121c1121 < uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char *sw_acl_token) --- > uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml) 1176,1179d1175 < // FK < char *sw_to_user; < char *sw_reg_host; < 1405,1410d1400 < // FK < if (sw_acl_token) { < switch_split_user_domain(sw_acl_token, &sw_to_user, &sw_reg_host); < to_user = sw_to_user; < reg_host = sw_reg_host; < } 2080,2081d2069 < // FK < char acl_token[512] = ""; 2159,2160d2146 < // FK < const char *token_sw = NULL; 2164c2150 < if (!(ok = switch_check_network_list_ip_token(network_ip, last_acl, &token_sw))) { --- > if (!(ok = switch_check_network_list_ip(network_ip, last_acl))) { 2171,2173d2156 < if (token_sw) { < switch_set_string(acl_token, token_sw); < } 2194c2177 < sofia_reg_handle_register_sw(nua, profile, nh, sip, de, type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL, acl_token); --- > sofia_reg_handle_register(nua, profile, nh, sip, de, type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL); I don't mean it to be integrated into FS core, if you don't want it to be. I am just willing to use it for our platform and would like your advices because I am not very confident about the dev done. Thanks all in advance! Florent Le 12/03/2014 17:11, Florent Krieg a écrit :
Hello Anthony,
Actually we only use the domains acl (I am not even sure what is 'real acl', we only use it in correlaton with cidr users' fields), automatically generated by scanning the user directory (we are in a multi-homed environment). Here is an example (taken out from the logs):
switch_utils.c:324 Adding XXX.XXX.XXX.XXX/32 (allow) [account@test] to list domains
With 'apply-inbound-acl=domains' and 'apply-register-acl=domains', when XXX.XXX.XXX.XXX tries to register with a random login@domain (eg: alice@alice, account which doesn't exist at all, assuming we only have 'account@test') to our platform, it goes OK. If we do a 'sofia_contact alice@alice', it returns the register from the db.
Now: * if we start a call, it will be authentified as 'account@test' (which is OK) * if we receive a call, we won't be able to get the contact for 'account@test' because the record in db is (to_user=)alice and (reg_host=)alice So in the last case we have to do static routing. We want to avoid it as much as possible.
I am not sure whether I am clear... Regards, Florent
Le 12/03/2014 15:42, Anthony Minessale a écrit :
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://irc.freenode.net> #freeswitch ? _http://freeswitch.org/g+_
ClueCon Weekly Development Call ? sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> ? +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-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
Florent, If you could provide a diff -u, remove the vanity comments as they aren’t allowed and we are trying to clean any left out of the tree. Any comments should be in full /* */ no short cuts of // if possible, Post it on jira.freeswitch.org and we’ll review it and provide feedback. Thanks, -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Mar 12, 2014, at 12:48 PM, Florent Krieg <fkrieg@sewan.eu> wrote:
Anthony, all,
I wrote a fix this afternoon based on a git master pull (which compiles and works like a charm after some tests). As I haven't done C programming in ages hence I'd be very grateful if one of you could tell me if the patch is very unstable/could cause a lot of troubles, and so on.
Here it is: [user@vm ~]# diff /root/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h /root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h 952c952 < uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, ---
uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, 955,956c955 < uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char *sw_acl_token); < #define sofia_reg_handle_register(_nua_, _profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_, _sofia_private_p_, _user_xml_) sofia_reg_handle_register_sw(_nua_, _profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_, _sofia_private_p_, _user_xml_, NULL)
uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml);
[user@vm ~]# diff /root/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c /root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c 1119c1119 < uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, ---
uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, 1121c1121 < uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char *sw_acl_token)
uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml)
1176,1179d1175 < // FK < char *sw_to_user; < char *sw_reg_host; < 1405,1410d1400 < // FK < if (sw_acl_token) { < switch_split_user_domain(sw_acl_token, &sw_to_user, &sw_reg_host); < to_user = sw_to_user; < reg_host = sw_reg_host; < } 2080,2081d2069 < // FK < char acl_token[512] = ""; 2159,2160d2146 < // FK < const char *token_sw = NULL; 2164c2150 < if (!(ok = switch_check_network_list_ip_token(network_ip, last_acl, &token_sw))) { ---
if (!(ok = switch_check_network_list_ip(network_ip, last_acl))) {
2171,2173d2156 < if (token_sw) { < switch_set_string(acl_token, token_sw); < } 2194c2177 < sofia_reg_handle_register_sw(nua, profile, nh, sip, de, type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL, acl_token); ---
sofia_reg_handle_register(nua, profile, nh, sip, de, type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL);
I don't mean it to be integrated into FS core, if you don't want it to be. I am just willing to use it for our platform and would like your advices because I am not very confident about the dev done.
Thanks all in advance! Florent
Hello Brian, Thanks for the guideline. I created an account on JIRA, but I don't see any way to post. Do I need to request rights on my account? I read https://wiki.freeswitch.org/wiki/Reporting_Bugs#Reporting_A_Bug_With_JIRA but couldn't find the information. Thanks in advance. Florent Le 12/03/2014 21:26, Brian West a écrit :
Florent, If you could provide a diff -u, remove the vanity comments as they aren't allowed and we are trying to clean any left out of the tree. Any comments should be in full /* */ no short cuts of // if possible, Post it on jira.freeswitch.org and we'll review it and provide feedback.
Thanks, -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com
T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
On Mar 12, 2014, at 12:48 PM, Florent Krieg <fkrieg@sewan.eu> wrote:
Anthony, all,
I wrote a fix this afternoon based on a git master pull (which compiles and works like a charm after some tests). As I haven't done C programming in ages hence I'd be very grateful if one of you could tell me if the patch is very unstable/could cause a lot of troubles, and so on.
Here it is: [user@vm ~]# diff /root/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h /root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h 952c952 < uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, ---
uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, 955,956c955 < uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char *sw_acl_token); < #define sofia_reg_handle_register(_nua_, _profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_, _sofia_private_p_, _user_xml_) sofia_reg_handle_register_sw(_nua_, _profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_, _sofia_private_p_, _user_xml_, NULL)
uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml);
[user@vm ~]# diff /root/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c /root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c 1119c1119 < uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, ---
uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t *profile, nua_handle_t *nh, sip_t const *sip, 1121c1121 < uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char *sw_acl_token)
uint32_t keylen, switch_event_t **v_event, const char *is_nat, sofia_private_t **sofia_private_p, switch_xml_t *user_xml)
1176,1179d1175 < // FK < char *sw_to_user; < char *sw_reg_host; < 1405,1410d1400 < // FK < if (sw_acl_token) { < switch_split_user_domain(sw_acl_token, &sw_to_user, &sw_reg_host); < to_user = sw_to_user; < reg_host = sw_reg_host; < } 2080,2081d2069 < // FK < char acl_token[512] = ""; 2159,2160d2146 < // FK < const char *token_sw = NULL; 2164c2150 < if (!(ok = switch_check_network_list_ip_token(network_ip, last_acl, &token_sw))) { ---
if (!(ok = switch_check_network_list_ip(network_ip, last_acl))) {
2171,2173d2156 < if (token_sw) { < switch_set_string(acl_token, token_sw); < } 2194c2177 < sofia_reg_handle_register_sw(nua, profile, nh, sip, de, type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL, acl_token); ---
sofia_reg_handle_register(nua, profile, nh, sip, de, type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL);
I don't mean it to be integrated into FS core, if you don't want it to be. I am just willing to use it for our platform and would like your advices because I am not very confident about the dev done.
Thanks all in advance! 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
I’ll make sure that gets fixed today for you, its a bug in the new signup system we are testing. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Mar 13, 2014, at 5:17 AM, Florent Krieg <fkrieg@sewan.eu> wrote:
Hello Brian,
Thanks for the guideline. I created an account on JIRA, but I don't see any way to post. Do I need to request rights on my account? I read https://wiki.freeswitch.org/wiki/Reporting_Bugs#Reporting_A_Bug_With_JIRA but couldn't find the information.
Thanks in advance. Florent
Thanks again Brian. For information (if other people are interested by this topic), the JIRA issue is FS-6353. Regards, Florent Le 13/03/2014 14:24, Brian West a écrit :
I'll make sure that gets fixed today for you, its a bug in the new signup system we are testing.
-- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com
T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
On Mar 13, 2014, at 5:17 AM, Florent Krieg <fkrieg@sewan.eu> wrote:
Hello Brian,
Thanks for the guideline. I created an account on JIRA, but I don't see any way to post. Do I need to request rights on my account? I read https://wiki.freeswitch.org/wiki/Reporting_Bugs#Reporting_A_Bug_With_JIRA but couldn't find the information.
Thanks in advance. 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
participants (3)
-
Anthony Minessale
-
Brian West
-
Florent Krieg