Hello, colleagues!
In In this material, we have acquainted ourselves with a useful and, as might be noticed, quite necessary element of VoIP infrastructure, namely the traffic monitoring system, or for brevity, TMS. We learned what it is, what tasks it addresses, and also highlighted the most prominent representatives introduced to the IT world by developers. In this part, we will discuss the principles based on which the implementation of TMS in the IT infrastructure and the monitoring of VoIP traffic is carried out.
Architecture of VoIP traffic monitoring systems
We built, built, and finally built. Hooray!
From the cartoon 'Cheburashka and Crocodile Gena'.
As mentioned earlier, there are quite a number of products in the telecommunications industry that fall into this category. However, if we abstract away the name, developer, platform, and so on, we can notice that they are all more or less the same in terms of architecture (at least those the author has dealt with). It should be noted that this is specifically related to the mere lack of any other methods for capturing traffic from network elements for its subsequent detailed analysis. Moreover, the latter is, in the author's subjective opinion, largely determined by the current development of various areas within the subject industry. For a clearer understanding, let’s consider the following analogy.
Since the moment the great Russian scientist Vladimir Alexandrovich Kotelnikov created the theorem of sampling, humanity has gained a monumental opportunity to perform analog-to-digital and digital-to-analog conversions of speech signals, enabling us to fully utilize such a remarkable form of communication as IP telephony. If we look at the development of speech signal processing mechanisms (also known as algorithms, codecs, encoding methods, etc.), we can see how DSP (digital signal processing) has made a fundamental leap in encoding informational messages – the implementation of the ability to predict speech signals. In other words, instead of simply digitizing and using a- and u-law compression (G.711A/G.711U), we now have the ability to transmit only a portion of the samples, with subsequent recovery of the entire message from them, significantly saving bandwidth. Returning to the subject of SMT, it should be noted that at the moment there are no similar qualitative changes in the approach to traffic capture, aside from various types of mirroring.
Let's refer to the figure presented below, which illustrates what has been built by specialists in the respective subject areas.
Figure 1. General architecture diagram of SMT.
Practically any SMT consists of two main components: a server and traffic capture agents (or probes). The server handles the reception, processing, and storage of VoIP traffic coming from the agents, and also provides specialists with the ability to work with the received information in various representations (graphs, diagrams, Call Flow, etc.). The capture agents receive VoIP traffic from the core network equipment (e.g., SBC, softswitch, gateways, etc.), convert it into a format used by the software employed by the server, and transmit it to the latter for further manipulation.
Just as composers create variations on the main melodies of their works in music, various implementations of the presented scheme are possible in this case. Their diversity is quite large and is mainly determined by the characteristics of the infrastructure in which the SMT is deployed. The most common variant is one where no capture agents are installed or configured. In this case, the analyzed traffic is directed directly to server or, for example, the server obtains the necessary information from pcap files generated by monitoring objects. This delivery method is typically chosen when it is not possible to install probes. The location of the equipment, lack of virtualization resources, flaws in the organization of the transport IP network, and, consequently, issues with network connectivity, etc., can all be reasons for choosing the noted variant of monitoring organization.
Having understood how a particular SMT can be integrated into the IT infrastructure from an architectural perspective, we will now consider aspects that fall more within the realm of system administrators, namely, the methods of deploying system software on servers.
During the preparation of a solution for implementing the monitoring network component in question, performers often have many questions. For example, what should be the composition of the server hardware, is it sufficient to install all system components on one host, or should they be separated, how to carry out the software installation, etc. The aforementioned and many other related questions are very broad, and the answers to many of them indeed depend on the specific operating (or design) conditions. However, we will try to generalize the specifics to get an overall picture and understanding of this aspect of SMT deployment.
So, the first thing that specialists always consider when implementing an SMT is what technical specifications to use for the server. Given the widespread availability of open-source software, this question has been raised so frequently that its popularity could perhaps be compared to the question "What should one do?" posed by Nikolai Gavrilovich Chernyshevsky... The main factor influencing the answer is the number of media sessions that the telephony platform is processing or will process. A concrete metric that provides a clear assessment of this factor is the CAPS parameter (Call Attempts Per Second) or the number of calls per second. The necessity of answering this question is primarily due to the fact that the information about sessions directed at the system will create the load on its server.
The second question that arises when deciding on the specifications of the server's hardware components is the composition of the software (operating environments, databases, etc.) that will operate on it. Signal (or media) traffic arrives at the server, where it is processed (parsed) by some application (for example, Kamailio), and the information formatted in a certain way is then stored in the database. For various SMTs, applications that defragment signal units and those that ensure storage may differ. However, they are all united by the nature of multithreading. At the same time, due to the characteristics of such an infrastructure element as an SMT, it should be noted here that the number of write operations to the disk significantly exceeds the number of read operations from it.
And finally… "How much is in this word": server, virtualization, containerization… The last, but very important aspect addressed in this part of the article, is the possible ways to install SMT components during its deployment. The technologies listed alongside the quote from the immortal work of A.S. Pushkin are widely used in various infrastructures and projects. On one hand, they are closely interconnected, and on the other hand, they differ significantly in many criteria. Nevertheless, all of them, in one form or another, are presented by developers as available options for installing their products. To summarize the systems mentioned in the first part of the article, we will note the following methods of deploying them on a physical server or virtual machine:
— using automated installation scripts or manual installation followed by configuration of the corresponding software,
— using a ready-made OS image with pre-installed SMT software and/or agents,
— using containerization technology (Docker).
The listed installation methods have their advantages and disadvantages, and specialists have their own preferences, limitations, and specific conditions in which the infrastructure they operate or implement exists, in order to voice any recommendations. On the other hand, the provided overview of the deployment paths for SIP traffic monitoring systems is quite transparent and does not require more detailed examination at this stage.
Thus, another article dedicated to an important and interesting element of the VoIP network – the SIP traffic monitoring system – has come to fruition. As always, I thank the readers for their attention to this material! In the next part, we will try to delve even deeper into the specifics and examine the products HOMER SIP Capture and SIP3.
Source: habr.com
