Voice Clerk Billing System
Introduction:
The main purpose of the professional VoIP billing system - Voice Clerk is to charge and limit the calls of a certain company's employees, aiming at the optimization of the expenses for phone calls in its inner infrastructure. Frequent use case of Voice Clerk is also distributing telephone bill expenses among many enterprise branches or subdivisions. For example, when customers receive the monthly telecom invoices, they face the challenge to split the invoice total among their branches; Voice Clerk helps our clients immensely to accomplish and automate this job.
The system allows collecting and storing information about the committed incoming and outgoing calls, through the organization, calculating their cost, blocking or notifying the users, who have reached an administratively assigned limit and generating a variety of different reports about the expenses.
Unlike many other existing systems on the market today, the incoming data for the calculations is received directly from end-point devices - the VoIP routers, that manage the incoming and outgoing calls (via the RADIUS protocol) or it can be gathered from the Call Data Record (CDR) database of Cisco Call Manager™ (CCM) in Cisco Systems based VoIP networks or similar DBs, supported by other vendors.
Voice Clerk's modular and robust architecture allows integrating it in such a way that it gets the data for calls carried out from many and different sources (e.g.via the RADIUS protocol from VoIP routers, from CDR database in an RDBMS or by fetching via telnet the information directly from a GSM gateway) and multiple VoIP equipment vendors.
Main features:
The main features of Voice Clerk include:
Robust support for precise calculation of the cost of (outgoing) calls, with support for all tariff methods supported by telecom providers (peak / off peak time zones, zones of destinations with different tariff settings, different pricing depending on the call duration etc)
Accounting of incoming calls
Support for processing of both VoIP and POTS (in which case usually there are VoIP routers connected via ISDN to the telephone network for making calls external to the organization's own VoIP infrastructure) telecoms
Support for integration with many different vendors (Cisco Systems, Siemens, Ericsson) and telecom equipment (voice routers, GSM gateways, telephone centrals), using different communication protocols, without modifications to the organization's VoIP infrastructure
Very high, telecom level performance and scalability (national scale integrations with 2-5 million calls per month, running on a single, commodity virtual machine and a dedicated DB server, with options to scale to meet client demand)
Options to restrict or send notifications (via e-mail) to users who have surpassed their administrative call cost limit
Full history support of user data: all modifications to extension, user etc data are kept in the DB; reverting to previous versions or restoring deleted entities is easily supported
Number translation subsystem: administrators can conveniently define translation rules to do different transformations on the called / calling numbers (e.g.drop the "outside line prefix", put the branch's prefix in front of partially received extension numbers etc)
Robust Role Based Access Controll (RBAC) subsystem for defining user permissions and privileges
Fully localized: web interface translations are available in English and Bulgarian, and adding more languages is trivial
Support for all major RDBMS products; especially optimized for MySQL and Oracle
A powerful web interface with numerous useful reports and administrative section
Easy exporting of report results for further manipulation in a spreadsheet program like MS Excel. Export in CSV or Excel formats
Product details:
Voice Clerk is a telecom grade VoIP billing system, built with the enterprise in mind. It has the performance, scalability, preciseness and robustness of professional telecom billing systems, but is also designed to work from within an organization having an internal VoIP network. Enterprises these days often have an internal VoIP network and numbering plan. This internal VoIP infrastructure has to be connected to the land-line and GSM providers so that users can also have external calls - incoming or outgoing. Usually this link to the outside world is implemented using dedicated VoIP routers, which connect to land-line providers via ISDN BRI or PRI interfaces and to the mobile ones often using FXO / FXS, ISDN or other interfaces to connect to a GSM gateway.
Modern VoIP equipment usually has built in functionalities for basic accounting of the calls carried out. VoIP equipment normally has no idea of call pricing, billing etc and all that is of concern to it is call duration, caller, callee, voice interface to use etc (some VoIP products support choosing optimal routes for calls - the so called Least-cost routing, but this has nothing to do with call cost calculation or billing). A VoIP billing system like Voice Clerk has to get access to this raw data for the calls, often reffered to as Call Detail Records - CDRs. There are different and vendor specific ways to export this information to other (billing) systems. Many modern VoIP products support the RADIUS protocol for accounting, authorization and authentication. Others keep the CDRs in a relational or other type of database. Voice Clerk's robust architecture allows it to connect to a miriad of different CDR sources (we've even had a case where - to achieve the highest possible precision - we had to integrate it with GSM gateways to fetch CDR data over Telnet) and can easily be extended to support even more!
Once integrated in an organization's VoIP infrastructure so that it can get its hands on the CDRs, Voice Clerk can start performing call cost calculations, limitation or notification via e-mail of users, who have spent too much time on the phone etc. The Voice Clerk web interface has plenty of useful reports, ways to export results, search options etc, which will help you optimize your VoIP infrastructure and excerscise control in the network. Our research has shown numerous times that the ROI (Return Of Investment) for Voice Clerk is very quick, because it helps enterprises quickly distribute telecom invoices among branches, analyse VoIP network usage, find and resolve problems (for example Voice Clerk makes it trivial to see if calls are being routed via any route but the optimal, least cost one) and generally to get the most out of their VoIP infrastructure.
Technical details::
RADIUS accounting and authorization:
As explained above, Voice Clerk can integrate with many and different sources of CDRs like RDBMSs, CSV files (recent versions of CCM export CDRs by uploading them in CSV files) etc. The most powerful method for collecting CDRs however is via the RADIUS protocol and we usually prefer this integration method because of its numerous advantages (fullest call information, live call processing - on call hang-up etc). Voice Clerk's billing kernel is built on top of the leading RADIUS server FreeRADIUS.
FreeRADIUS is a robust and high performance, open source RADIUS server with support for many authentication, authorization and accounting backend protocols. The RADIUS based implementation of the Voice Clerk kernel extends the FreeRADIUS server with custom accounting modules to fascilitate the complex billing processing, supported by the platform.
Here's a simplified explanation of how RADIUS accounting generally works:
- An user places an outgoing (or receives an incoming) call
- Since the call is external, it reaches the VoIP router, which connects it to the land-line telephone network via an ISDN port
- When the call is finished and the user hangs up, a RADIUS accounting packet is sent to the Voice Clerk server, containing all information needed for billing the call
- Voice Clerk's kernel processes the received accounting packet, calculates the cost of the call and stores it in the database
Limitation and notifications:
The RADIUS protocol can be used not only for accounting purposes, but also for authentication and authorization (the 3 big As of IT security: AAA). When limitation of user calls is enabled in Voice Clerk, its kernel processes also the RADIUS authorize packets (along with the accounting ones) sent by the VoIP gateways. Cisco Systems VoIP routers do not by default send RADIUS authorize packets, but a custom TCL script can be uploaded on the routers in order to implement limitation (the call processing engine of Cisco Systems VoIP routers is implemented as a State Machine and can be customized with Tool Command Language - TCL scripts to overwrite what actions are to be executed if a given event occurs and depending on the state of the call). Here's a simplified description of the call limitation process:
- Whenever an user initiates an outgoing call, the TCL script deployed on the VoIP gateway sends a RADIUS authorize packet to the Voice Clerk server to verify if the user is authorized to place the call
- The Voice Clerk server issues 2 database queries - to sum up the cost of all user calls for the current billing period and to fetch the user's call limit
- If the user has not exhausted her limit, Voice Clerk responds positively to the authorize packet and the gateway lets her place the call (and the normal accounting process continues; also if an user approaches her limit, a timer is set on the gateway to tear down the call when the limit is exhausted and play a warning message)
- If the user has exhausted her limit, Voice Clerk responds negatively to the authorize packet and the gateway redirects the call to play a "Limit exhausted" message to the user and then tears it down
Most of our clients however don't favour the drastic approach of limitation and instead prefer to send e-mail notifications to users who have been talking too much on the phone. This approach is also much simpler, because it doesn't require resorting to RADIUS authorization (and the associated TCL script uploading etc). Each user again has an associated limit, but instead of dropped calls, users who have exhausted their limit get an e-mail message with a kind reminder to restrict their personal conversations.
The described above limitation / notification mechanisms can seamlessly work together as well. In fact the Voice Clerk administrator can, using the web interface, always choose the "limitation type" for each user. The options include: normal (authorize based), notification, unrestricted or blocked entirely.
Cisco VoIP router RADIUS setup:
Here is a brief how-to on Cisco voice router configuration for RADIUS accounting:
aaa new-model
aaa group server radius voiceclerk
server _IP_ auth-port _PORT_ acct-port _PORT_
ip radius source-interface _IFACE_
aaa accounting connection h323 stop-only group voiceclerk
gw-accounting aaa
radius-server host _IP_ auth-port _PORT_ acct-port _PORT_ key _KEY_
radius-server vsa send accounting
aaa accounting connection h323 {stop-only | start-stop | none} [broadcast] group voiceclerk
NOTE: Enabling the "aaa new-model" directive changes the authentication model used by the router and can cause inability to login or gain administrator access! This happens because with this command you also by default enable the router to use RADIUS for authentication, not its local account DB. Always check if you can login normally (from another session / terminal) before disconnecting and take measures to restore your access if needed!
You can define a group of RADIUS (Voice Clerk) servers to be used in either a round-robin (for load balancing) or broadcast (for high availability) fashion, with the "aaa group server radius..." line. In the group you define one or more RADIUS servers with IP address and ports for authentication and accounting. The "ip radius source-interface" line specifies the interface on the router via which it will communicate with the RADIUS server. The "aaa accounting connection h323" line enables accounting for voice calls and the "gw-accounting aaa" one turns on gateway accounting globally. The "radius-server" lines define the parameters of the RADIUS server - IP, ports and an encryption key (secret word). The "radius-server vsa send accounting" line tells the router to send Cisco Vendor Specific Attributes (VSA) with more details in accounting packets. The last line in the configuration example shows the syntax of the "aaa accounting connection" command in detail.
Other CDR retrieval methods:
Versions 5.x and above of CCM export CDRs in CSV files by uploading them via FTP or SFTP. Voice Clerk can then parse these files and process the calls as usual. Older MS Windows based CCM versions store CDRs in an MS SQL server RDBMS. Voice Clerk can be configured to connect to the MS SQL servers and fetch the CDRs from there. For that to work, the CCM administrator needs to enable network connections via TCP/IP on the MS SQL server (usually on TCP port 1433). Also the MS SQL server account used for communication by Voice Clerk has to be setup for SQL Server authentication (not Windows authentication).
Voice provider trunks on the VoIP routers and IP-to-IP gateways:
Enterprises often connect to external VoIP telecom providers over SIP or other protocols. For this they need to set up a trunk to the provider either on the CCM (in which case CDRs can be gathered only from the CCM), or on the VoIP routers themselves using the IP-to-IP gateway technology. The IP-to-IP gateway integration can work via the RADIUS protocol and thus has all the advantages associated with that. In order to support IP-to-IP gateways, Voice Clerk just needs to be configured to process RADIUS accounting VoIP originate packets, along with the usual Telephony originate ones (for outgoing calls; for incoming calls the last call legs are VoIP / Telephony answer).
Links and documentation:
