Traffic monitoring systems in VoIP networks. Part Two - Principles of Organization

Hello colleagues!

Π’ previous In the material, we got acquainted with such a useful and, as you can see, a rather necessary element of the VoIP infrastructure, as a traffic monitoring system or, for short, CMT. We learned what it is, what tasks it solves, and also noted the brightest representatives presented by the developers to the IT world. In this part, we will consider the principles according to which the implementation of CMT into the IT infrastructure and monitoring of VoIP traffic by its means is carried out.

Traffic monitoring systems in VoIP networks. Part Two - Principles of Organization

Architecture of monitoring systems for VoIP traffic

We built, built and finally built. Hooray!
From the cartoon "Cheburashka and Crocodile Gena".

As noted earlier, there are enough products in the communications and telecommunications industry that fall into the appropriate category. However, if we ignore the name, developer, platform, etc., then you can see that they are all more or less the same in terms of their architecture (at least those that the author had to deal with). It should be noted that this is due precisely to the simple absence of any other ways to collect traffic from network elements for its subsequent detailed analysis. At the same time, the latter, in the subjective opinion, is largely determined by the current development of various areas of the subject industry. For a clearer understanding, consider the following analogy.

From the moment the great Russian scientist Vladimir Aleksandrovich Kotelnikov created the sampling theorem, mankind has received a tremendous opportunity to perform analog-to-digital and digital-to-analog conversion of speech signals, thanks to which we can fully use such a wonderful type of communication as IP telephony. If you look at the development of speech signal processing mechanisms (aka algorithms, codecs, coding methods, etc.), you can see how DSP (digital signal processing) has taken a fundamental step in encoding information messages - the implementation of the ability to predict a speech signal. That is, instead of just digitizing and using a- and u-laws of compression (G.711A/G.711U), now it is possible to transmit only a part of the samples with subsequent recovery of the entire message from them, which significantly saves bandwidth. Returning to the topic of CMT, we note that at the moment there are no similar qualitative changes in the approach to capturing traffic, except for one or another type of mirroring.

Let us turn to the figure below, which illustrates what was built by experts in the relevant subject areas.

Traffic monitoring systems in VoIP networks. Part Two - Principles of Organization
Figure 1. General scheme of the SMT architecture.

Almost any CMT consists of two main components: a server and traffic capture agents (or probes). The server receives, processes and stores VoIP traffic that comes from agents, and also provides specialists with the ability to work with the information received in various views (graphs, diagrams, Call Flow, etc). Capture agents receive VoIP traffic from the network core equipment (for example, SBC, softswitch, gateways, ..), convert it into the format used in the system server software used, and transfer it to the latter for subsequent manipulations.

As in music, composers create variations on the main melodies of works, so in this case, various options for implementing the above scheme are possible. Their diversity is quite large and is mainly determined by the characteristics of the infrastructure in which the TMS is deployed. The most common option is one that does not install or configure capture agents. In this case, the analyzed traffic is sent directly to the server, or, for example, the server receives the necessary information from pcap files generated by monitoring objects. This delivery method is usually chosen if it is not possible to install probes. The location on the equipment placement site, lack of resources for virtualization tools, flaws in the organization of the transport IP network and, as a result, problems with network connectivity, etc., all this may be the reason for choosing the noted option for organizing monitoring.

Having learned and understood how this or that CMT can be implemented in the IT infrastructure from an architectural point of view, we will further consider aspects that are more within the competence of system administrators, namely, ways to deploy system software on servers.

In the course of preparing a decision on the implementation of the considered component of the monitoring network, performers always have many questions. For example, what should be the composition of the server hardware, is it enough to install all system components on one host or is it worth separating them from each other, how to install software, etc. The questions listed above, as well as many other related questions, are very broad, and the answers to many of them really depend on the specific operating (or design) conditions. However, we will try to generalize the specifics in order to get a general idea and understanding of this side of the CMT deployment.

So, the first thing that is always of interest to specialists when implementing CMT is what performance characteristics should the server be used with? Given the widespread use of free software, this question is asked so many times that its popularity can probably be compared with the question β€œWhat to do?”, Asked by Nikolai Gavrilovich Chernyshevsky… The main factor influencing the answer is the number of media sessions that are processed or will be processed by the telephony platform. A numerical and tangible characteristic that gives a specific assessment of the noted factor is the CAPS (Call Attempts Per Second) parameter or the number of calls per second. The need to answer this question is primarily due to the fact that it is the information about sessions sent to the system that will create a load on its server.

The second issue that arises when deciding on the characteristics of the server's hardware components is the composition of the software (operating environments, databases, etc.) that will function on it. Signal (or media) traffic arrives at the server, where it is processed (parsed signal messages) by some application (for example, Kamailio), and then the information formed in a certain way is placed in the database. For different CMTs, both the applications that defragment the signal units and the applications that provide storage may be different. However, they are all united by the same nature of multithreading. At the same time, due to the peculiarities of such an infrastructure element as CMT, in this paragraph it should be noted that the number of write operations to disk significantly exceeds the number of read operations from it.

And finally ... "How much in this word": server, virtualization, containerization ... The last but very important aspect touched upon in this part of the article is the possible ways to install CMT components when it is deployed. Listed next to a quote from the immortal work of A.S. Pushkin technologies are widely used in various infrastructures and projects. On the one hand, they are closely interconnected with each other, and on the other hand, they differ strikingly in many criteria. Nevertheless, all of them, in one form or another, are presented by developers as available options for installing their products. Generalizing for the systems listed in the first part of the article, we note the following ways to deploy them on a physical server or virtual machine:
- use of automatic installation scripts or self-installation and subsequent configuration of the corresponding software,
- use of a ready-made OS image with pre-installed SMT software and / or agent,
- use of containerization technology (Docker).

The listed installation tools have their advantages and disadvantages, and specialists have their own preferences, limitations and specific conditions in which the infrastructure they operate or implement is located in order to voice any recommendations. On the other hand, the above description of the ways to deploy SIP traffic monitoring systems is quite transparent, and at the current stage does not require its more detailed consideration.

This turned out to be another article dedicated to an important and interesting element of the VoIP network - the SIP traffic monitoring system. As always, I thank the readers for their attention to this material! In the next part, we will try to delve even more into the specifics and consider the HOMER SIP Capture and SIP3 products.

Source: habr.com

Add a comment