CDR is divided into two types: Legacy (Conventional) CDR and Survivable CDR

Contents

How to get call log history Business Management Books
My company uses a telephone network distributed over the territory of the UK

I would like to share my experience in setting up call logging in a corporate telephone network built on the basis of Avaya Aura solutions (under the control of Communication Manager - hereinafter referred to as CM). Data is collected based on CDR (Call Detail Recording). This article is of an overview nature, in it I describe the basic principles of solving the problem that has arisen.

My company uses a telephone network distributed over the territory of the UK with more than 5000 IP-stations (telephones used by employees). The task was to write a logger for outgoing external (directed to the PSTN) calls from internal subscribers (including tandem calls) with the subsequent addition of the tariffication functionality. Internal calls (within the telephone network) and incoming calls were not of interest, but the described method of collecting information allows us to process such types of calls. There are several ready-made commercial solutions for charging calls, some of them we tested in our company, but often the cost of these products did not match the level of usability and quality of implementation.

If the details of the implementation of certain points are interesting, I can dwell on them in more detail 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 on early CM releases, 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 binding the CDR link to the IP address of the receiving host), and in the second, all the accumulated information is written to the hard disk ESS or LSP of the PBX server ... Legacy CDR operates in "listen-only" mode, when on the other side of the CDR-link there is a client (let's call it a logger), which receives a data stream in text form arriving at a specified port like this: https://callgear.com/vpbx/call-logs-and-data/. If the logger for some reason stops receiving information, the server starts accumulating data into a buffer, after which the CDR link goes down. And from that moment on, all information about calls ceases to be logged, which leads to the appearance of gaps in the collected data. In the case of Survivable CDR, everything is different: CDR data is written to disk in the form of text files and stored there until they are deleted manually or automatically when a certain limit on the number of files is reached. For 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 exist, for example, when the CM version is on your PBX does not support Survivable CDR).

In the case of the Legacy CDR, you can use any network logger (even a self-written one) - a program that collects and processes data read from a network port. I used ADVANCED PBX DATA LOGGER - a very powerful, high-quality and intuitive logger that can be easily configured to receive information from a given port, parsing according to custom templates and return digestible data to a database or file. In addition, I was lucky to get a license for this product in exchange for describing the format of the data transmitted by our PBX :) For the initial testing of CDR output, the Netcat utility can also be useful, which will allow you to "listen" to data on the network port. For Survivable CDR, you do not need to deal with setting up a third-party logger or write your own bike - at least knowledge of some scripting language that can connect via SFTP to the server, receive and parse a text file and add the received data to the database is enough. For example, you can use PHP for this, which is also useful for organizing the web interface of the billing system. All processed files can be deleted from the server with the same script. If the script for some reason does not run on time, then the data will accumulate for a long time (in comparison with Legacy CDR, where the buffer overflows in several hours with a large number of calls), and later it can be received in full.

The description of the output data format, the rules for naming the Survivable CDR files, as well as all the necessary CM settings are in the Avaya Aura Feature Description and Implementation document (you can easily find it 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 CDR data to the logger, all information is accumulated in a structured way in the database. Now you need to charge the logged calls and display all the information in a beautiful and convenient form. This is where my web programming experience came in handy, and I used PHP and JS languages ​​to create a web interface for the tariff planner.