-
Notifications
You must be signed in to change notification settings - Fork 22
Home
FBilling can easily be split into two parts - backend, which is responsible for main call flow logic, and frontend responsible for management and reports.
FBillings logic is written in Perl and consists of single AGI script and related libraries.
Main component - fbilling.agi - is executed every time outbound call attempt is made and take control over rest call flow. Several checks are performed (does account exist, does extensions have right credit and permission, if tariff and prefixes exist and so on) and if all checks are passed, call is passed to its destination - FreePBX trunk or remote gateway. If check fails at some stage call is terminated - and in future user/extension will be notified about cause of termination.
It is important to note, that by itself, FBilling backend is not dependent in any way on FreePBx, and in theory, it can work on any Asterisk based system, provided that it is properly configured.
For Administration FBilling relies on its frontend - FreePBX module, of course written in PHP. Module provides capabilities to configure almost any FBilling related aspect, and plus, offers reporting interface for call detail records.
FBilling uses components to represent its paradigms and data, and each of these are outlined below:
Tenants are sets of extensions. The main idea behind tenantsis that, once FreePBX is installed, extensions created in FreePBX can be grouped - no matter what those groups represent, branch offices, departments, room numbers or even different organisations - those groups are tenants for FBilling logic.
Grouping extensions in tenants offer several advantages:
- Tenants can be deactivated, so extension from deactivated tenants won't be able to make outbound calls;
- Tenants can have different tariffs, so two extensions from different tenants can make outbound call to same destination, but cost of these calls will be different due to different tariffs;
- Call detail records can be filtered by tenants thus providing more clear picture of outbound calls.
If there is no need to have multiple tenants on one server - user can create just one "General" tenant and joing all extensions in that one tenant.
Weights help to set permissions for accounts, for example, weights "Local", "Toll Free" and "Long Distance" can be defined, and then destination can be assigned to these weights. This helps to set dialing permissions for extensions - extension 100 can have permission to dial only destinations belonging to "Toll Free" weight, while extension 200 can have permission to dial "Toll Free" and "Long Distance" destinations and so on.
Permissions are sets of weights, e.g. one can create permission "Free" which will comprise of weights "toll Free" and "Local". Extensions are given those permissions. So permission has many weights, has many extensions. Call detail records can also be filtered with weights - thats more detailed analytics.
If we speak in Asterisk terminlogy - prefixes are like dial patterns. Prefixes are very iportant for FBilling logic, since every dialed number is matched against FBilling Prefix. It is also important to note that at this stage, FBilling does not support duplicate prefixes. To explain concept of Prefixes - say, we have defined prefixes 1800 and 1. extension dialed number 18003882475, so FBilling will lookup prefix database against dialed number and pull one prefix that is best match - in thiscase prefix 1800, so FBilling will proceed in it's logic. If extension dialed number 4401344393440, and we do not have any prefix that starts with 4 (4, 44, 44013 and so on) FBilling will hangup call and report back that destination prefix for dialed number was not found. To speak more simply, Prefixes can be country codes or area codes. Though how prefixes are defined is totally dependent on user, it is recommended to use E.164 dialing format as reference when planning prefix management. Each prefix can (and should) be assigned to weight.
Tariffs are pretty self explanatory - tariff is per minute or one time cost of destination/prefix. Tariffs are bound to tenants, so fo one prefix, one can have as many tariffs as number of tenants defined in system. E.g. we have two Tenants "San Francisco" and "Salt Lake City", we have prefix 1800. Two tariff can be created for this prefix each for tenant - so, San Francisco can have tariff with per minute cost of 0.04 for prefix 1800, and tenant Salt Lake City can have tariff with per minute cost of 0.09 for prefix 1800. So extensions belonging to these two different tenant will be able to dial 1800 numbers but cost will be different. It must be noted that one tenant can not have more that one tariffs for one prefix.
Trunks are initial destination for call - that is IP address of remote gateway or peer/trunk defined in FreePBX. Each trunk is associated with tariff, so when extension dials the number, and it's corresponding prefix and tariff is found, call is routed through tariff's corresponding trunk - prior to sending number to destnation FBilling can manipulate dialed number - strip or add digits. So trunks have many tariffs.