I decided to fill in these gaps and make my own contribution, this information will be informative and useful for beginners, more experienced users can emphasize something new for themselves, in any case we will all be in the black. The plans at the moment are big - to write a cycle of posts, summarizing the knowledge I have gained, for obvious reasons I will not post assemblies, virtual machines, etc., the most important thing is to direct, and the one walking will find his way.
Perhaps the lyrics are enough, let's start as always with theory. Since this post will be read by users with different levels of knowledge, I will try to explain everything briefly and clearly.
Introduction
A software IP-PBX is an automatic telephone exchange based on the IP protocol, the "brain" of which is special software that implements voice switching (in this case, voice packets) and other services provided to subscribers.
Now let's figure out how all this works, I will not describe in detail right away, it will take a lot of time, and therefore there will be some incorrectness and omissions.
The subscriber picks up the phone and enters the number, the signaling is immediately triggered, which will control the session of the voice stream, for this there are a number of protocols of which two SIP and H.323 can be distinguished. At the moment SIP has gained a lot of popularity and in this post it will be considered. Further, we will assume that a logical connection was established between subscribers using the SIP protocol, and then voice is needed.
The subscriber speaks into the phone - his voice is encoded using a software or hardware codec into a set of bits. Codec - voice compression algorithm, the simplest and most common PCMA. Then these bits are sent to the addressee using the RTP protocol.
To summarize all of the above, then we have the SIP protocol that controls the communication session, it includes the SDP protocol, which describes the session (used and available codecs and other information), these protocols are packed into TCP or UDP transport and using the IP protocol sent in the specified direction. As soon as a logical connection is established, the voice is compressed using the codec and packaged in RTP and sent using the IP protocol to the addressee.
Now let's try to answer the main question: who controls all this? Software switch or softswitch for short is the “brain” of a software IP-PBX that manages all internal and external interactions. Softswitch is well known to us, everyone has heard about Asterisk and Freeswitch. There are paid ones, there are free ones, there are with a graphical interface, there are without.
In Figure 1, I depicted a block diagram of a software IP-PBX, but consider it in more detail. First of all, it is an operating system (OS), it must be compatible with hardware, have the necessary repositories and be convenient for work. We won't talk about hardware, let it be some kind of server. Based on the wishes of the customer (TOR), the “brain” of our IP-PBX - Softswitch is selected, it can be the same Asterisk or Freeswitch or a Softswitch written by hand. In the figure, I divided Softswitch and software, in fact it can be one application, it all depends on the requirements of the customer, you can take a ready-made, the same Freeswitch, write a program that will manage it and also implement additional functionality. Everything is clear with the Web server, we need a layer between the http client and Softswitch. Well, and accordingly the database,we will not constantly rewrite configuration files. The OS gives us an environment for work, it is also necessary to write additional drivers if we want to connect the FXO and E1 boards.
Fig 1. Block diagram of a software IP-PBX
Now you can breathe out, the theory described is very compressed, but is needed for further understanding of the material.
Sipp and StarTrinity SIP Tester
A few weeks ago, the task was set - to test the load that our software IP-PBX can withstand. After a long search, I came across a free Sipp call generator and paid StarTrinity SIP Tester. Below I will briefly describe the capabilities of these applications.
Perhaps I'll start with the simplest - with StarTrinity SIP Tester. The application works only under Windows, has a huge number of features, user registration, act as a registration server, send outgoing calls with many parameters, receive incoming calls and send the specified messages, in fact you can write the script yourself and the application will help you with this. But all the functionality is the topic of a separate post, we need the most basic thing for work - the ability to send calls at a given interval, without forgetting about RTP. And now the most important thing is that this application is paid, but the developers also provide a free slightly stripped-down version, but in fact even a stripped-down version can be used if you are smart.
The free version allows you to make 150 calls, while there can be 50 simultaneous connections. But after the reboot, the counter is reset and you can send calls again. Figure 2 and 3 show the StarTrinity SIP Tester application, we can see what address, to which number, from whom, what codec, interval and other call information. It is also worth noting that there is a Web interface and the ability to make scripts myself, but what I didn’t like is that you can’t do scripts with the wrong parameters.
Figure 2. Paid version of StarTrinity SIP Tester
Figure 3. Free version of StarTrinity SIP Tester
If StarTrinity SIP Tester is a beautiful graphical interface that is ready to work out of the box, then Sipp presented itself to me as a kind of “monster” that needs to be downloaded, compiled, and the necessary packages added. But as it turned out, this should not be feared, the developers have left an excellent guide on the site describing the installation process and the capabilities of this application. They immediately warn that it will take several days to learn how to write scripts, but this is the plus, you will thoroughly understand the sip protocol itself and study its fields. A few words, there are built-in scripts, they sent and accepted the most common calls, we are still looking for the rest on the Internet, some users are sharing, but I had to sit to study the specifications and write my scripts. Sipp is available for Windows and Linux, but it works more stable under Linux.
Now to the point, it is expensive to allocate a machine only for Sipp, we take and make a virtual machine, I use VirtualBox under Ubuntu, I had no problems. Installed in accordance with the guide, go to the application folder and launch the application with the necessary keys.
Fig 4. Sipp call generator
I will not describe the Sipp functionality, it is similar to StarTrinity SIP Tester, which application is better, there is no definite answer, I came to the conclusion that they complement each other perfectly.
Stress Testing
Now we know what a software IP-PBX is and how it works, we also know the functionality of call generators.
Again, when testing, we must understand the operating mode of the software IP-PBX: proxy mode (RTP + signaling is proxied), semi-proxy (only signaling is proxied), request redirection (message 300). It will depend on whether we need to enable RTP in some scenarios or not. In Figure 5, I have sketched several test cases.
Option 1 - we test the software IP-PBX in transit mode, for this we need two different PCs. On the PBX, we register a route, respectively, from one Sipp / StarTrinity SIP Tester, we generate calls to another Sipp / StarTrinity SIP Tester. I'll tell you right away with StarTrinity SIP Tester on Sipp (or vice versa) I did not try to generate calls, but purely in theory they should be fully compatible.
Option 2 - we test the software IP-PBX in transit mode, for this we need two different PCs. On the PBX, we register the route, respectively, from one Sipp / StarTrinity SIP Tester we generate calls to Asterisk. For Asterisk I use a VirtualBox virtual machine under Ubuntu, I had no problems. In the Asterisk dialplan, write the following:
When you call this number, Asterisk answers and sends all the received voice back.
Fig. 5. Equipment configuration options for load testing.
Option 3 - we test the software IP-PBX in the terminal station mode, for this we need one PC and IP-phones, we set auto-answer on the phones. We register IP phones on the PBX, respectively, from one Sipp / StarTrinity SIP Tester we generate calls to them.
Option 4 - we test the software IP-PBX in the terminal station mode, for this we need one PC and analogue TA. We set up analogue TAs on the PBX, respectively, from one Sipp / StarTrinity SIP Tester we generate calls to them. As far as I know, but I have not encountered it, there are certain devices that connect to analog lines and can be programmed, for example, to pick up the phone when you call, but if there is no such possibility, you will have to manually pick up the handsets.
That's all, of course we turn on the logs on the software IP-PBX, or display the console with debugging and look at the errors that have occurred. This is how the performance and failure limits can be determined. By the way, advice, install Wireshark, tshark, tcpdump on the virtual machine, so you can monitor and analyze all traffic on your interface in real time.
Summarizing
To summarize, we superficially familiarized ourselves with the construction of a software IP-PBX and Sipp and StarTrinity SIP Tester call generators and learned to simulate the load. If you think about it, you can safely test the entire Sip stack with these call generators.
That's all for today, I am waiting for your comments and remarks, if you want to share your experience, I will only be glad.
LOADING…
Links
1.Sipp sipp.readthedocs.io/en/v3.6.0/#
2.StarTrinity SIP Tester startrinity.com/VoIP/SipTester/SipTester.aspx
3.Books and other information asterisk.ru/knowledgebase/books