AudioCodes SBC Performance


    Good day to all! 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 examine in detail the test results of AudioCodes by an independent company Miercom, which specializes in conducting independent testing. This company has tested almost all the leading manufacturers of SBC. Read the review of the test result under the cat.

    The most productive SBC models were tested, namely: Mediant 4000 (supports up to 5000 simultaneous connections), Mediant 9000 (aka 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. 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 conducted not only by the number of sessions, but also by many performance parameters:
    Number of simultaneous connections with manipulation of SIP headers, SIP UDP <-> SIP TCP conversions, encryption, transcoding of various codecs, WebRTC, etc.



    The first test was performed on the performance of signaling sessions without taking into account the proxying of voice traffic. The result of this test: maximum performance with SIP conversion + SIP UDP conversion <-> SIP TCP Mediant 9000 / VE is 32000 signal sessions + 500 CPS (Call Per Seconds - call attempts per second. The Mediant 4000 has a lower value, namely 5000 signal sessions + 120 CPS. But it should be noted right away that signal sessions are understood as one call without proxying voice traffic. Actually, because of this, Mediant 9000 / VE results are higher than what we write officially, since all brochures contain data performance proxied . I voice traffic should be noted that during the SBC testing done following manipulation: Removes the SIP field added SIP field




    A separate item is testing the highest load. The idea is that with normal traffic growth (for Mediant 4000 - 120 CPS), suddenly there is too much load for 10 seconds (in the test for Mediant 4000, it was 500 CPS). The test result showed that with such a sudden load, the SBC is capable of processing up to 190 CPS. For Mediant 9000 / SE, this value reached 500 CPS, while increasing productivity to 2000 CPS. Moreover, this testing was done for both Mediant 9000 and virtual SBC, and the results do not differ.

    Next, tests were made in the most commonly used scenario, when the SBC holds both signal and voice sessions. Tests fully confirmed the performance information that we publish on our site. Namely:
    1. When proxying the most commonly used G.711 codec, 20 ms:
      • Mediant 4000 - Supports up to 5000 concurrent calls
      • Mediant 9000 - Support for up to 24,000 concurrent calls
      • Mediant VE (Virtual SBC) - Support for up to 6,000 concurrent calls
    2. When converting IPv4 <-> IPv6
      • Mediant 4000 - Supports up to 5000 concurrent calls
      • Mediant 9000 - Support for up to 24,000 concurrent calls
      • Mediant VE (Virtual SBC) - Support for up to 6,000 concurrent calls
    3. When converting RTP <-> SRTP
      • Mediant 4000 - Supports up to 5000 concurrent calls
      • Mediant 9000 - Support for up to 16,000 concurrent calls
      • Mediant VE (Virtual SBC) - Supports up to 4000 concurrent calls




    Next are the transcoding tests. Moreover, the tests are quite interesting, since they take into account not only the conversion of G.711 20 ms to G.729 20 ms, but also the conversion of G.711 to SILK and OPUS. SILK is a codec that is used in the Skype solution and has long ago confirmed that it is an excellent codec for voice transmission on complex IP channels, such as the Internet in hotels, etc. The OPUS codec is an open codec promoted by Google. This codec takes the SILK codec as the basis for transmitting voice information, but since it is a universal codec that is also designed to store media information, working with it is more complicated. 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.

    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 simultaneous connections
    • G.711 <-> SILK: 400 simultaneous connections
    • G.711 <-> OPUS: 320 simultaneous connections




    Mediant 9000 was not involved in this test.

    During testing, not only the number of sessions was taken into account, but also the quality of transcoding on the MOS scale. The quality when transcoding to the G.729 codec drops to the level of 3.88 (the standard quality of G.711 is 4.2). This is due to the peculiarity of the G.729 codec, which alone cannot provide the best quality. If we talk about the conversion of SILK and OPUS codecs, then the quality remains at the level of 4.2. That is, voice quality does not deteriorate when converting from G.711. When transcoding better HD codecs in SILK and / or OPUS, the quality will be higher, since the original codec is of higher quality than G.711. As a result of these tests, AudioCodes complies with the declared specifications for converting voice codecs, while fully maintaining voice quality. For more information on the number of transcoding sessions,

    The following test is especially relevant for telecom operators. SBC performance for increment registrations. 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 up are more complex tests. One of them is the speed with which the SBC is able to register the declared number of devices. These tests are important in cases where those subscribers who fall off suddenly suddenly begin to register en masse. As an example, the channel to the data center fell off, or a large area was left without electricity for some time. The results of this test:
    1. Mediant 4000: 67 seconds (i.e. around 300 registrations per second)
    2. Mediant 9000: 75 seconds (i.e. 1600 registrations per second)
    3. Mediant VE: only 20 seconds (i.e. 1600 registrations per second, just like the Mediant 9000)

    Well, now those same tests for DoS / DDoS attacksthat various telecom operators like to ask about. Naturally, for telecom operators this is most relevant, since various DoS / DDoS attacks, with the aim of breaking in (selecting passwords) or simply disabling the service, are an integral part of the life of any operator. And here it is important to continue to provide service even during attacks. Such attacks, as a rule, fall on those operators or clients who allow VoIP connections from the public Internet. As an example, this can be connecting smartphones or softphones via SIP from the Internet to company employees who travel frequently and travel on business. In this case, it is necessary, on the one hand, to save money on roaming companies, 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 the recognized market leader in the Ixia traffic generator, connected through one switch to SBC (Some of the tests were carried out using the Open-source SIP traffic generation solution - PROTOS). We tested 15 types of different attacks, at a time when maximum traffic was simultaneously running on the SBC, both in terms of the number of sessions and in terms of connection growth. 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 SBC and the equipment continued to process existing calls and accept new ones. If we talk about the details of the results of these tests, then this can be presented in the form of a tablet for the most popular types of attacks:
    Attack
    Attack description
    Result Mediant 4000
    Result Mediant 9000
    SYN Flood
    44,000 TCP SYN packets per second (pps) sent to signal port 5060.
    This test was performed when establishing a connection without RTP proxing, since only SIP signaling was checked.
    It does not affect the work in any way, despite the fact that the SBC was under a load of 5000 simultaneous connections and a call growth of 122 per second
    It does not affect the work in any way, despite the fact that the SBC was under a load of 32,000 (Mediant 9000) simultaneous connections and an increase in calls of 500 per second
    UDP FLOOD
    50,000 UDP pps, which is about 400 Mbps, sent to the SBC network port.
    It does not affect the work in any way, despite the fact that the SBC was under a load of 5,000 simultaneous connections and an increase in calls of 122 per second. Despite the fact that the MOS value of voice traffic did not fall and remained at the level of 4.2 (standard for the G.711 codec).
    It does not affect the work in any way, despite the fact that the SBC was under a load of 24,000 (Mediant 9000) simultaneous connections. Despite the fact that 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
    It does not affect the work in any way, despite the fact that the SBC was under a load of 5000 simultaneous connections and a call growth of 122 per second
    It does not affect the work in any way, despite the fact that the SBC was under a load of 32,000 (Mediant 9000) simultaneous connections and an increase in calls of 500 per second.
    SIP Fuzzing
    18,000 invalid messages per second (Mpbs) that are not compliant with the RFC standard
    It does not affect the work in any way, despite the fact that the SBC was under a load of 5000 simultaneous connections and a call growth of 122 per second
    It does not affect the work in any way, despite the fact that the SBC was under a load of 32,000 (Mediant 9000) simultaneous connections and an increase in calls of 500 per second.
    ICMP Flood
    52,000 ICMP pps (200 Mbps) routed to SBC voice ports
    When fully loaded in 5,000 simultaneous connections, this attack does not affect the quality of communication. The MOS value for the G.711 codec remains at level 4.2, which is the standard for G.711
    When fully loaded in 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 level 4.2, which is the standard for G.711

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

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

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

    The second test is more complicated. Namely, when the equipment is installed in HA (High Availability) mode and at the time the device is fully loaded, the main SBC simply shuts down. In this scenario, all types of SBC worked correctly. I will explain. All existing connections moved to the standby SBC and the service did not stop. New calls began to be successfully established on standby SBC. The only thing is that the calls that were in the connected state at the time of switching (that is, the call has already been initiated, but the connection has not been made, for example, the call was in the process of dialing) ended, but switching of these connections according to the architecture is not provided.

    WebRTC
    An additional test is not on performance, but on 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 API of the browsers themselves. WebRTC is currently supported by the following platforms / browsers - Google Chrome, Android Chrome, Mozilla Firefox, Opera. Quite a lot of articles have been written on this subject on the hub (for example, here: http://habrahabr.ru/post/187270/), all of them basically described the scenario 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 ensure that AudioCodes SBC can take over WebRTC and translate it into standard SIP. WebRTC testing scheme is presented below:



    AudioCodes SBC accepts WebRTC calls with the OPUS codec and translates them towards the Skype For Business server 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. 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. Also, as an option, you can connect to the TDM PBX through the stream E1. The test results showed that AudioCodes SBC fully terminates WebRTC using protocols such as: DTLS, ICE Light, SIP over Secure Web Socket, RTP and RTCP multiplexing, and transcoding the OPUS broadband codec to the G.711 codec or any other that is required .

    As we can see from the results of this testing, AudioCodes SBC can be used on the network of enterprises or telecom operators, while ensuring guaranteed operation under the declared load, providing full protection for your network. Only the AudioCodes most productive SBCs participated in the Miercom tests, but I will also add a performance table for the 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

    Also popular now: