Logging and tariffing of outgoing calls for Avaya PBX

I want to share the experience of setting up call logging in the corporate telephone network built on the basis of Avaya Aura solutions (under the control of Communication Manager - hereinafter referred to as CM ). Data collected on the basis of CDR ( Call Detail Recording ). This article is an overview, in it I describe the basic principles of solving the problem.
My company uses a telephone network distributed over the territory of the Russian Federation with more than 5,000 IP stations (telephone sets used by employees). The task was to write a logger of outgoing external (sent to the PSTN) calls from internal subscribers (including tandem calls) with the subsequent addition of the functionality of the caller. Internal calls (within the telephone network) and incoming calls were not interested, but the described method of collecting information allows you to handle these types of calls. There are several ready-made commercial billing solutions for calls, some of them we had to test in our company, but often the cost of these products did not correspond to the level of usability and quality of implementation.

If the details of the implementation of certain points will be interesting, I can elaborate on them in another article, so as not to overload this one, or tell in a personal.

Theory

CDR is divided into two types: Legacy (Conventional) CDR and Survivable CDR . The first type was mainly used in early releases of CM, until a more convenient and flexible mechanism appeared - Survivable CDR. The difference is that in the first version all CDR data is “broadcast” over the network to the so-called CDR adjunct (by linking the CDR link to the IP address of the receiving host), while in the second all the accumulated information is recorded on the ESS or LSP server's PBD . The Legacy CDR operates in the “listen-only” mode when there is a client on the other side of the CDR link (let's call it logger ), which receives a data stream arriving at a given port in text form. If, for some reason, the logger stops receiving information, the server begins to accumulate data into a buffer, after filling in which the CDR link goes down . From this point on, all information about calls stops logging, which results in gaps in the collected data. In the case of a Survivable CDR, everything is different: CDR data is written to the disk as text files and stored there until it is deleted manually or automatically when a certain limit on the number of files is reached. For the Legacy CDR, you can use not one, but two CDR links (two independent loggers on different hosts, which increases the reliability of the mechanism), but the second collection method is more convenient and reliable (the first method also has the right to life, for example, when the CM version on your PBX does not support a survivable CDR).
In the case of the Legacy CDR, you can use any network logger (albeit self-written) —a program that collects and processes data read from the network port. I used ADVANCED PBX DATA LOGGER - a very powerful, high-quality and intuitive logger, which is easily configured to receive information from a given port, parsing using customizable templates and returning digestible data to a database or file. Besides, I was lucky to get a license for this product in exchange for a description of the format of the data transferred to our PBX :) The Netcat utility can also be useful for initial testing the performance of the CDR, which will allow you to “listen” on the network port.
For a Survivable CDR, you do not need to understand the configuration of a third-party logger or write your own bike - all you need is to know some scripting language that can connect via SFTP to the server, retrieve and parse a text file, and add the data to the database. For example, for this you can use PHP, which is also useful for organizing the web interface of the caller. All processed files can be deleted from the server using the same script. If the script for some reason does not work on time, the data will accumulate for a long time (in comparison with the Legacy CDR, where the buffer is full in a few hours with a large number of calls), and later can be received in full.
A description of the format of the output, the naming rules for the Survivable CDR files, and all the necessary CM settings are in the Avaya Aura Feature Description and Implementation document (it is easy to find on the official support site ). You can configure the CM to return strictly specified fields in the desired order (the so-called Formated Output ).

Billing

So, CM is configured to return the CDR data to the logger, all information is accumulated structured in the database. Now you need to charge billed calls and display all the information in a beautiful and convenient way. This is where web programming experience came in handy, and I used the PHP and JS languages ​​to create a web interface for the caller.
First, I collected from various Internet sources a table of prefixes of telephone numbers, with the help of which the direction of the call is determined - the subject of the Russian Federation and the corresponding federal district. Tables of prefixes were used that are available on the sites of large telecom operators ( MTT , Rostelecom , Comstar , etc.), as well as Wikipedia .
Then, for each trunk group, on the basis of information from telecom operators used in the company, tariff tables were created that set the cost of a minute of a call through a trunk group to each entity. Here the following difficulty arose: calls to city numbers within one subject may differ in cost due to tariffing by distance from the city, and not by belonging to the subject. It was necessary to divide such subjects into separate zones: for example, split up the Moscow region into districts. In general, the task of drawing up tariff tables is solved individually, depending on the form in which your telephony provider provides its tariffs. Ideally, of course, you need to achieve a table with prices set for each subject or city, but this is not always possible.
The data collected by the logger is run through the tables of prefixes and tariffs, and fields with direction and cost are added for each call.
One of the features of the CDR in this PBX - rounding the duration of the call in 6-second intervals. Another important point: the problem arises of breaking call logs on different database tables (depending on the data size, you can, for example, start a new table every month) - otherwise the selection from the database will be too long.
The mechanism for obtaining data about the owner of the internal number (extension) from Active Directory was bolted to the caller. Also, a mechanism for filtering the displayed data by date / time of the call, duration, caller and receiver numbers, etc. is implemented. - you can make a selection on any of the fields given in the CDR (including types of calls, account codes, FRL, etc.)
')
So, if there are specialists at Habré who would like to implement their own logger and / or outgoing call tariffing for Avaya PBX, I’m ready to share my experience to the best of my abilities