Hi, I know ACL is to block or allow an IP to reg or call. But in practise, if an IP is allowed then it won't check the User directory again so cannot match to the user info stored in the user directory and dialplan route to the public context. <node type="allow" cidr="192.168.1.123/32"/> 2013-07-28 22:11:04.647358 [DEBUG] sofia.c:7915 IP 192.168.1.123 Approved by acl "domains[]". Access Granted. 2 If I set the cidr attribute in the user directory, but it seems been parsed to the ACL so it also allows any other users to reg or call from that url. Below is a log that shows Access Granted when I actually set the cidr to 1000 but calling with 1001. FS doesn't challenge 1001. 2013-07-28 22:07:14.347320 [DEBUG] sofia.c:7915 IP 192.168.1.123 Approved by acl "domains[1000@192.168.1.123 (mailto:1000@192.168.1.123)]". Access Granted. 2013-07-28 22:07:14.347320 [DEBUG] sofia.c:8045 Authenticating user 1000@192.168.1.123 (mailto:1000@192.168.1.123) Is it a problem? Is it possible to check the ip *and* the user? e.g. user 1000 can only reg from ip IP with password 1234. Thanks. -- Seven Du http://www.freeswitch.org.cn http://about.me/dujinfang http://www.dujinfang.com Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
If acl is set, then it won't check the user directory. The IP in the user directory authorizes without checking the auth. if you want to check the IP along with the user, then I think you have to do that in the dial plan... I don't think it's built into FS. -Avi On Jul 28, 2013 5:43 PM, "Seven Du" <dujinfang@gmail.com> wrote:
Hi,
I know ACL is to block or allow an IP to reg or call. But in practise, if an IP is allowed then it won't check the User directory again so cannot match to the user info stored in the user directory and dialplan route to the public context.
<node type="allow" cidr="192.168.1.123/32"/>
2013-07-28 22:11:04.647358 [DEBUG] sofia.c:7915 IP 192.168.1.123 Approved by acl "domains[]". Access Granted. 2
If I set the cidr attribute in the user directory, but it seems been parsed to the ACL so it also allows any other users to reg or call from that url. Below is a log that shows Access Granted when I actually set the cidr to 1000 but calling with 1001. FS doesn't challenge 1001.
2013-07-28 22:07:14.347320 [DEBUG] sofia.c:7915 IP 192.168.1.123 Approved by acl "domains[1000@192.168.1.123]". Access Granted. 2013-07-28 22:07:14.347320 [DEBUG] sofia.c:8045 Authenticating user 1000@192.168.1.123
Is it a problem?
Is it possible to check the ip *and* the user? e.g. user 1000 can only reg from ip IP with password 1234.
Thanks.
-- Seven Du http://www.freeswitch.org.cn http://about.me/dujinfang http://www.dujinfang.com
Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
_________________________________________________________________________ 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've read the transfer application should just change destination_number and context, but this is not what I'm seeing happen if the call starts with freetdm. I have logged the span info in the answering extension - which works - but after the transfer it looks like the data is not available for the regex? But after it fails the Regex it executes the log lines but because it didn't see the variable it fails.. ... EXECUTE FreeTDM/2:1/ log(chan_name [FreeTDM/2:1/]) 2013-07-28 11:29:25.677884 [DEBUG] mod_dptools.c:1539 [FreeTDM/2:1/] EXECUTE FreeTDM/2:1/ log(freetdm_span_name FXO) 2013-07-28 11:29:25.677884 [DEBUG] mod_dptools.c:1539 FXO EXECUTE FreeTDM/2:1/ log(freetdm_span_number 2) 2013-07-28 11:29:25.677884 [DEBUG] mod_dptools.c:1539 2 EXECUTE FreeTDM/2:1/ log(freetdm_chan_number 1) 2013-07-28 11:29:25.677884 [DEBUG] mod_dptools.c:1539 1 EXECUTE FreeTDM/2:1/ transfer(my_voicemail XML features) 2013-07-28 11:29:25.677884 [DEBUG] switch_ivr.c:1815 (FreeTDM/2:1/) State Change CS_EXECUTE -> CS_ROUTING 2013-07-28 11:29:25.677884 [DEBUG] switch_core_session.c:1334 Send signal FreeTDM/2:1/ [BREAK] 2013-07-28 11:29:25.677884 [DEBUG] switch_core_session.c:854 Send signal FreeTDM/2:1/ [BREAK] 2013-07-28 11:29:25.677884 [NOTICE] switch_ivr.c:1822 Transfer FreeTDM/2:1/ to XML[my_voicemail@features] 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:477 (FreeTDM/2:1/) State EXECUTE going to sleep 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:415 (FreeTDM/2:1/) Running State Change CS_ROUTING 2013-07-28 11:29:25.677884 [DEBUG] switch_channel.c:2034 (FreeTDM/2:1/) Callstate Change ACTIVE -> RINGING 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:470 (FreeTDM/2:1/) State ROUTING 2013-07-28 11:29:25.677884 [DEBUG] mod_freetdm.c:453 FreeTDM/2:1/ CHANNEL ROUTING 2013-07-28 11:29:25.677884 [DEBUG] mod_freetdm.c:456 [s2c1][1:3] Indicating PROCEED in state UP 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:117 FreeTDM/2:1/ Standard ROUTING 2013-07-28 11:29:25.677884 [INFO] mod_dialplan_xml.c:557 Processing <0000000000>->my_voicemail in context features Dialplan: FreeTDM/2:1/ parsing [features->dx] continue=false Dialplan: FreeTDM/2:1/ Regex (FAIL) [dx] destination_number(my_voicemail) =~ /^dx$/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->att_xfer] continue=false Dialplan: FreeTDM/2:1/ Regex (FAIL) [att_xfer] destination_number(my_voicemail) =~ /^att_xfer$/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->is_transfer] continue=false Dialplan: FreeTDM/2:1/ Regex (FAIL) [is_transfer] destination_number(my_voicemail) =~ /^is_transfer$/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->cf] continue=false Dialplan: FreeTDM/2:1/ Regex (FAIL) [cf] destination_number(my_voicemail) =~ /^cf$/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->please_hold] continue=false Dialplan: FreeTDM/2:1/ Regex (FAIL) [please_hold] destination_number(my_voicemail) =~ /^([1-2][0-9])$/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->is_zrtp_secure] continue=true Dialplan: FreeTDM/2:1/ Regex (FAIL) [is_zrtp_secure] ${zrtp_secure_media_confirmed}() =~ /^true$/ break=on-false Dialplan: FreeTDM/2:1/ ANTI-Action eval(not_secure) Dialplan: FreeTDM/2:1/ parsing [features->is_secure] continue=true Dialplan: FreeTDM/2:1/ Regex (FAIL) [is_secure] ${sip_via_protocol}() =~ /tls/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->my_voicemail] continue=false Dialplan: FreeTDM/2:1/ Regex (PASS) [my_voicemail] source(mod_freetdm) =~ /(.*)/ break=never Dialplan: FreeTDM/2:1/ Action log(source ${source}) Dialplan: FreeTDM/2:1/ Action log(freetdm_span_number ${freetdm_span_number}) Dialplan: FreeTDM/2:1/ Action log(destination_number ${destination_number}) Dialplan: FreeTDM/2:1/ Regex (FAIL) [my_voicemail] freetdm_span_number() =~ /2/ break=on-true Dialplan: FreeTDM/2:1/ Regex (FAIL) [my_voicemail] source(mod_freetdm) =~ /^mod_sofia$/ break=on-false Dialplan: FreeTDM/2:1/ parsing [features->flite] continue=false Dialplan: FreeTDM/2:1/ Regex (FAIL) [flite] destination_number(my_voicemail) =~ /^99$/ break=on-false 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:167 (FreeTDM/2:1/) State Change CS_ROUTING -> CS_EXECUTE 2013-07-28 11:29:25.677884 [DEBUG] switch_core_session.c:1334 Send signal FreeTDM/2:1/ [BREAK] 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:470 (FreeTDM/2:1/) State ROUTING going to sleep 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:415 (FreeTDM/2:1/) Running State Change CS_EXECUTE 2013-07-28 11:29:25.677884 [DEBUG] switch_channel.c:2036 (FreeTDM/2:1/) Callstate Change RINGING -> ACTIVE 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:477 (FreeTDM/2:1/) State EXECUTE 2013-07-28 11:29:25.677884 [DEBUG] mod_freetdm.c:473 FreeTDM/2:1/ CHANNEL EXECUTE 2013-07-28 11:29:25.677884 [DEBUG] switch_core_state_machine.c:209 FreeTDM/2:1/ Standard EXECUTE EXECUTE FreeTDM/2:1/ eval(not_secure) EXECUTE FreeTDM/2:1/ log(source mod_freetdm) 2013-07-28 11:29:25.677884 [DEBUG] mod_dptools.c:1539 mod_freetdm EXECUTE FreeTDM/2:1/ log(freetdm_span_number 2) 2013-07-28 11:29:25.677884 [DEBUG] mod_dptools.c:1539 2 EXECUTE FreeTDM/2:1/ log(destination_number my_voicemail) This might be a bug -- I tried matching with both <condition field="freetdm_span_number" expression="2" break="on-true"> and <condition field="freetdm_span_number" expression="^2$" break="on-true"> The bigger question is just what does transfer do with a freetdm call? My understanding is transfer should simply change destination_number and context and reparse the dialplan? -------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 The Prius: A car for people that don't have math skills. The Volt: A car for people with even worse math skills. kps --------------------------------------------------------------------------------
participants (3)
-
Avi Marcus
-
Karl Schmidt
-
Seven Du