AudioCodes SBC performance

Good day everyone! AudioCodes has a certain number of SBC models, each of which has a specific performance. I will not rewrite our brochures, which describe the characteristics, as this information is freely available on our website. This article will detail the results of testing AudioCodes independent company Miercom, which specializes in conducting independent testing. This company has tested almost all leading manufacturers of SBC. Review test result read under the cut.

The most productive SBC models came under testing, namely: Mediant 4000 (supports up to 5000 simultaneous connections), Mediant 9000 (also known as software SBC, supporting up to 24,000 simultaneous connections) and Virtual SBC (supporting up to 6000 simultaneous connections). Virtual SBC worked on the VMWare platform. The test results in the original in English are available here.

On the Miercom website, this result is available only to registered users.

On an alternative source (does not require registration): download link
')
Testing was carried out not only by the number of sessions, but also by many performance parameters:
The number of simultaneous connections with the manipulation of SIP headers, SIP UDP <-> SIP TCP transforms, encryption, transcoding of various codecs, WebRTC, etc.



The first test was carried out on the performance of the signaling sessions without regard to voice traffic proxying. The result of this test: maximum performance with SIP + SIP UDP conversion <-> SIP TCP Mediant 9000 / VE is 32000 signaling sessions + 500 CPS (Call Per Seconds - call attempts per second. For Mediant 4000, the value is lower, namely 5000 signaling sessions + 120 CPS. But here we must immediately note that signaling sessions mean one call without proxying voice traffic. Actually, because of this, the Mediant 9000 / VE had better results than what we write officially, since all brochures contain data by performance taking into account proxied I voice traffic should be noted that during testing SBC made the following manipulations:. Remove the field SIP, SIP added field modified SIP field and converts SIP UDP in the TCP SIP and vice versa.

A separate item is testing the highest load. The idea is that with a normal increase in traffic (for Mediant 4000 - 120 CPS), all of a sudden there is too much load for 10 seconds (in the test for the Mediant 4000, it was 500 CPS). The test result showed that with such a sudden load, the SBC is capable of handling up to 190 CPS. For the Mediant 9000 / SE, this value reached 500 CPS, with an increase in performance of up to 2000 CPS. Moreover, this testing was done for both the Mediant 9000 and the virtual SBC, and the results are no different.

Further tests were made in the most frequently used scenarios, when the SBC has both signal and voice sessions on it. The tests fully confirmed the performance information that we publish on our site. Namely:

1. When proxying the most commonly used G.711 20 msc codec:
   
   • Mediant 4000 - support up to 5000 simultaneous calls
   • Mediant 9000 - support up to 24,000 simultaneous calls
   • Mediant VE (Virtual SBC) - support up to 6000 simultaneous calls
2. When converting IPv4 <-> IPv6
   
   • Mediant 4000 - support up to 5000 simultaneous calls
   • Mediant 9000 - support up to 24,000 simultaneous calls
   • Mediant VE (Virtual SBC) - support up to 6000 simultaneous calls
3. When converting RTP <-> SRTP
   
   • Mediant 4000 - support up to 5000 simultaneous calls
   • Mediant 9000 - support up to 16,000 simultaneous calls
   • Mediant VE (Virtual SBC) - support up to 4000 simultaneous calls

Next come the transcoding tests. Moreover, the tests are quite interesting, since they take into account not just the G.711 20 ms conversion to G.729 20 ms, as well as the G.711 conversion to SILK and OPUS. SILK is a codec used in the Skype solution and it has long been confirmed that it is an excellent codec for transmitting voice on complex IP channels, such as the Internet in hotels, etc. The OPUS codec is an open codec promoted by Google. This codec is based on the SILK codec as the basis for transmitting voice information, but since it is a universal codec that is also designed to save media information, working with it is more complex. When viewed from a practical point of view, the SILK codec is used in Microsoft’s Skype For Business solutions, and the OPUS codec is used in the WebRTC solution. If we consider competitive solutions, not all SBCs support these codecs, and no one, except us, conducted load testing.

Test results below:

Mediant 4000	Mediant ve
G.711 <-> G.729: 5000 simultaneous connections G.711 <-> SILK: 4050 simultaneous connections G.711 <-> OPUS: 3850 simultaneous connections	G.711 <-> G.729: 420 Concurrent Connections G.711 <-> SILK: 400 simultaneous connections G.711 <-> OPUS: 320 Concurrent Connections

Mediant 9000 did not participate in this testing.

During testing, not only the number of sessions was taken into account, but also the quality of transcoding according to the MOS scale. When transcoding to G.729 codec, the quality drops to 3.88 (G.711 standard quality is 4.2). This is due to the feature of the G.729 codec, which by itself cannot provide better quality. If we talk about converting SILK and OPUS codecs, the quality remains at the 4.2 level. That is, voice quality does not deteriorate when converted from G.711. When transcoding higher quality HD codecs to SILK and / or OPUS, the quality will be higher, since the original codec has a higher quality than G.711. As a result of these tests - AudioCodes complies with the declared characteristics of voice codec conversion, with full preservation of voice quality. For more information on the number of transcoding sessions, please refer to the release notes.

The following test is particularly relevant for telecom operators. SBC performance on registration gains. The first test simply shows the maximum number of registrations from remote devices. The results are as follows:

1. Mediant 4000: 20,000 registrations
2. Mediant 9000: 120,000 registrations
3. Mediant VE: 30,000 registrations

Next come the more complex tests. One of them is the speed with which the SBC is able to register the stated number of devices. These tests are important in cases where those subscribers who fall off, suddenly begin to register en masse. As an example, the channel to the data center fell off, or a large area for some time remained without electricity. The results of this test:

1. Mediant 4000: 67 seconds (i.e. about 300 logs per second)
2. Mediant 9000: 75 seconds (i.e. 1600 registrations per second)
3. Mediant VE: just 20 seconds (i.e. 1600 registrations per second, as well as Mediant 9000)

Well, now those very tests for DoS / DDoS attacks , about which various telecom operators like to ask. Naturally, for telecom operators, this is most relevant, since various DoS / DDoS attacks, with the aim of hacking (selecting passwords) or simply putting the service out of service, are an integral part of the life of any operator. And here it is important, even during attacks, to continue providing the service. Under such attacks, as a rule, those operators, or clients, who allow VoIP connection from the public Internet, fall. As an example, this may be the connection of smartphones or softphones via SIP from the Internet for company employees who often travel and are on business trips. In this case, you need, on the one hand, to save the company money on roaming, on the other hand, to provide a secure connection without the possibility of hacking.

Now about the results and testing methodology. Testing was carried out with the help of a recognized market leader in the Ixia traffic generator, connected via a single switch to the SBC (Some of the tests were carried out using the Open-source SIP traffic generation solution - PROTOS). 15 types of various attacks were tested, at the moment when the maximum traffic went parallel to the SBC, both in terms of the number of sessions and in terms of the growth of connections. The duration of each attack was 5 minutes:

• ARP Flood
• Evasive UDP
• Land attack
• Ping-of-death
• Ping sweep
• Rst flood
• TCP scan
• Teardrop
• Surf attack
• SYN Flood
• UDP Flood
• UDP Scan
• Unreachable host
• Xmas tree attack

The testing scheme is presented below:


All tests were successfully passed. That is, these attacks did not affect the current work of the SBC and the equipment continued to handle existing calls and accept new ones. If we talk about the details of the results of these tests, then this can be represented as a label for the most popular types of attacks:

Attack	Attack description	Mediant 4000 result	Result Mediant 9000
SYN Flood	44,000 TCP SYN packets per second (pps) directed to signaling port 5060. This test was performed when establishing a connection without RTP proxying, since only SIP signaling was tested.	Does not affect the work, despite the fact that the SBC was under load of 5000 simultaneous connections and an increase in calls to 122 per second	Does not affect the work, despite the fact that the SBC was under load 32,000 (Mediant 9000) simultaneous connections and an increase in calls to 500 per second
UDP FLOOD	50,000 UDP pps, which is about 400 Mbps, directed to the SBC network port.	Does not affect the work, despite the fact that the SBC was under load of 5000 simultaneous connections and an increase in calls to 122 per second. Moreover, the MOS value of voice traffic did not fall and remained at the level of 4.2 (standard for the G.711 codec).	Does not affect the work, despite the fact that the SBC was under load 24 000 (Mediant 9000) simultaneous connections. Moreover, the MOS value of voice traffic did not fall and remained at the level of 4.2 (standard for the G.711 codec).
Unknown address	18,000 (56,000 for Mediant 9000 / VE) SIP messages per second (200 Mbps for 18,000 packets) sent to SBC from unknown addresses	Does not affect the work, despite the fact that the SBC was under load of 5000 simultaneous connections and an increase in calls to 122 per second	Does not affect the work, despite the fact that the SBC was under load of 32,000 (Mediant 9000) simultaneous connections and an increase in calls to 500 per second.
Sip fuzzing	18,000 incorrect messages per second (Mpbs) that do not comply with the RFC standard	Does not affect the work, despite the fact that the SBC was under load of 5000 simultaneous connections and an increase in calls to 122 per second	Does not affect the work, despite the fact that the SBC was under load of 32,000 (Mediant 9000) simultaneous connections and an increase in calls to 500 per second.
ICMP Flood	52,000 ICMP pps (200 Mbps) for SBC voice ports	When fully loaded into 5,000 simultaneous connections, this attack does not affect the quality of communication. The MOS value for the G.711 codec remains at 4.2, which is the standard for G.711	With a full load of 24,000 (6000 for VE) simultaneous connections, this attack does not affect the quality of communication. The MOS value for the G.711 codec remains at 4.2, which is the standard for G.711

These results are provided by the built-in IDS (Intrusion Detection System), which provides detection of malicious attacks and provides dynamic blocking of addresses of intruders and with periodic verification of address data. The system also provides information on the attack via SNMP, thus helping to take the necessary measures as quickly as possible to stop this attack. Based on the results of these tests, we can safely say that the SBC fully protects the voice network from various types of attacks.
Separately, I would like to mention that AudioCodes is one of the first SBC manufacturers to successfully pass Miercom DDoS attacks for Virtual SBC with Virtual Function Virtualization.

fault tolerance
Separate testing was conducted in terms of system fault tolerance. There were two types of tests. Both tests were carried out under the condition of full loading of SBC with proxying of voice RTP traffic in the G.711 codec.

The Mediant 4000/9000 architecture (as well as the other hardware SBC line) is such that all interfaces are duplicated and work in active / standby mode. This is done so that the SBC can be connected to different switches on the same network. If something happens to one of the switches, then the SBC detects the fall of this channel and automatically switches to the second port. The first is a test for testing the interface in active / standby mode. The active network interface through which voice RTP traffic went was disabled. The result of the switching speed and the start of work in the bilateral mode of the second network interface: Mediant 4000 - 10.3 msec., Mediant 9000 - 10.2 msec. All calls are preserved. In both cases, this service break is not displayed on the call quality. According to MOS, in both cases the quality remained at level 4.2.

The second test is more difficult. Namely, when the equipment is installed in HA (High Availability) mode and when the device is fully loaded, the main SBC is simply turned off. In this scenario, all types of SBC worked correctly. I will explain. All existing connections moved to the backup SBC and the service did not stop. New calls began to be successfully established on the backup SBC. The only point is that the calls that were at the moment of switching in the connection state (that is, the call was already initiated, but the connection did not occur, for example, the call was in progress), but the switching of these connections according to the architecture is not provided.

Webrtc
Additional test not for performance, but for functionality. WebRTC is a standard that is being developed as an open standard for communication between Web browsers and mobile applications, which uses the simple APIs of the browsers themselves. At the moment WebRTC is supported by the following platforms / browsers - Google Chrome, Android Chrome, Mozilla Firefox, Opera. On this topic, quite a lot of articles were written on Habré (for example, here: http://habrahabr.ru/post/187270/ ), all of them basically described the script of calls between two Web browsers. In this case, one of the clients is not a Web browser, but AudioCodes SBC. The purpose of this test is to make sure that AudioCodes SBC can take over WebRTC and translate it into standard SIP. The testing scheme of WebRTC is presented below:



AudioCodes SBC accepts WebRTC calls with the OPUS codec and transmits them to the Skype For Business server side using the standard SIP and G.711 codec. In this case, instead of Skype For Business server, you can use any PBX that supports SIP or any softswitch. The SBC also checks the correctness of the number through LDAP, thus providing additional control over the sessions, if this solution is used within the enterprise. Just as an option, you can connect to TDM PBX via E1 stream. The test results showed that AudioCodes SBC fully terminates WebRTC on itself using protocols such as: DTLS, ICE Light, SIP over Secure Web Socket, RTP and RTCP multiplexing, and transcoding the OPUS wideband codec to G.711 codec or any other .

As we can see from the results of this test, AudioCodes SBC can be used on a network of enterprises or telecom operators, while ensuring guaranteed work under the stated load, ensuring full protection of your network. Only the most productive SBCs of the company AudioCodes took part in the Miercom tests, but also add a performance table for younger models:

Characteristic	Mediant 500	Mediant 800	Mediant 1000	Mediant 2600	Mediant 3000
Number of sessions	250	250	150	600	1008
Transcoding	-	thirty	96	600	1800
fault tolerance	+	+	-	+	+
Number of registrations	800	800	600	8,000	3,000
WebRTC support	-	+	-	+	-
Availability of TDM interfaces	FXO, FXS, E1	FXO, FXS, E1	FXO, FXS, E1	-	E1, STM-1