How to Run SBC Stress-tests

We welcome our customers to verify the performance of the Session Border Controllers we offer on amazon Marketplace. The test-case orchestrated using this Cloud Formation template shows that a basic configuration on an m3.medium machine achieves the target performance of 180 parallel calls. That is achieved even when media streams are anchored at the SBC and all signaling is stored persistently at Monitor in PCAP format. Performance can be significantly higher when media anchoring is not used.

In this use-case, you will launch a cloud formation stack that will auto-start a one-hour stress-test with load incrementally increasing and then decreasing again. The load can be monitoring using CloudWatch.

How to Use It

To start the cloud formation process visit the following link:

You must choose your SSH key in parameters, and you may change the maximum stress load, for example above the engineered load of 180 to 248 to study overload conditions. You may also choose different configurations: with media anchoring at SBC (stresstest) versus direct RTP client-to-server (stresstestnonat)

Once the cloud formation process completes which takes several minutes, the Outputs will show the following links:

  • CWDAshboard is a link to Cloud Watch DAshboard which collects measurement data for the stress-test.
  • MonitorURL is a link to Monitor that shows in details what’s happening inside the SBC

After an hour you should be able to see a CloudWatch dashboard like bellow (the media anchoring version): the stress-load increases step-wise till the maxium and then returns step-wise to the beginning. The CPU usage follows the number of maximum calls. The engineered load of 180 parallel calls stresses the CPU bellow 100%. Under overload, CPU remains constantly at 100%. The worst-case RTP packet loss is contained even under overload conditions to 0.5%.

After the stress-test is finished, don’t forget to delete the cloud formation stack to make sure that you will not continue to be charged for the testbed.

You can also compare the media-anchoring performance to signaling only. Another test-run is showing that the same SIP load which overloaded the SBC machines with media anchoring is making it busy at 16% with media SBC bypass.


What Is Orchestrated

In the middle of this setup, there is the Session Border Controller (SBC)  which is using a m3.medium instance. An m5.large instance generates SIP calls with RTP traffic towards the SBC using SIPp testing tool. The SBC forwards the traffic to another m5.large instance. Depending on the SBC configuration, the RTP media also visits the SBC or bypasses it and is sent directly from traffic source to traffic sink. Additionally a monitoring instance is started to collect usage data from the SBC. All of the machines are started in a new independent VPC to make sure the stress-test doesn’t interfere with other machines. A STEP function is steering the load “stair-case” and is backed by several lambda functions.

What Else You Should Know

In this case to guarantee net measurement results, security features such as transaction throttles or automated blacklisting are turned off. See the “DoS case” for how to use these. These and other features may potentially influence the overall performance, positively or negatively. If you need a detailed analysis of performance, contact Frafos professional services.