[Freeswitch-users] how to identify caller based on CIDR for billing

[Muhammad Naseer Bhatti]

This is not a problem. I can set several CIDR(s) for a single user. If an
IP address exists in the DB, the system will not allow any other user to
enter that IP address for him. This is different. I match the account with
incoming network_addr of the caller. Since I am saving currently everything
as /32 and static match the IP address from the DB, so I get the account
code no problem. FS accepts the range happily. /24 or whatever, issue is
only how to process that information when it hits the dialplan and later
mangled by the scripts to parse.

On Mon, Feb 27, 2012 at 12:36 AM, Avi Marcus <avi at avimarcus.net> wrote:

> I suppose the issue is that each extensions seems to only have one CIDR
> option per directory-extension.
> I use the variable accountcode for billing.. so a hack would be to create
> users e.g. 1234-a, 1234-b, 1234-c each with their own CIDR and the same
> accountcode of 1234.
>
> Does someone else have a recommendation of how to enter several ranges of
> IPs for ACL for a particular user?
> -Avi
>
>
>
> On Sun, Feb 26, 2012 at 10:55 PM, Muhammad Naseer Bhatti <
> nbhatti at gmail.com> wrote:
>
>> Hello,
>> In order to allow ACL authentication, ACL is defined for FreeSWITCH and
>> IP address is entered in CIDR format. A /32 will have only 1 IP and /24
>> will have 254 IP address range. Now, FS will allow the call if the IP
>> address falls under the subnet. For example, caller IP address is
>> 192.168.10.24 while the ACL node is defined as 192.168.10.0/24. This
>> works fine, but when it come to identify the incoming call for billing
>> purpose, how can we identify the IP address matches to which customer? Or
>> which ACL node for FreeSWITCH. One possible solution is to expand the CIDR
>> used by FS, and then match the caller IP address, but I guess this will
>> take too much resources. Am I missing something here? Or restrict the user
>> to enter only 1 IP address per account?
>>
>> Thanks,
>> Goni
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120227/2fcdb117/attachment-0001.html