Improving real-time communication (RTC) client experience with AWS Global Accelerator

Introduction

AWS Global Accelerator is a networking service that decreases latency, delivers greater performance, and achieves higher availability for internet traffic between your users and your applications running on AWS. By leveraging Global Accelerator, customers can achieve up to 60% better performance for internet traffic. In this blog post, we discuss the performance (voice quality, call setup time, call success rate) improvements delivered with AWS Global Accelerator. In addition, we walk you through configuration steps to setup an accelerator for your Voice over IP (VoIP) workloads in real-time communication (RTC) environment, and explain the way for you to do your own end-to-end performance testing to assess the benefits of AWS Global Accelerator for your deployment.

In the telecommunications industry, real-time communication (RTC) refers to live media sessions between users. RTC applications include voice over IP (VoIP), video conferencing, and messaging. We expect the readers to be familiar with VoIP terminologies and architectures. Real-Time Communication on AWS white paper provides and overview of these topics.

Benefits of AWS Global Accelerator

Global Accelerator provides two static IP addresses for each accelerator. These IP addresses are anycast and are advertised globally via AWS edge locations. Using accelerators that you configure, Global Accelerator routes TCP or UDP traffic to the application endpoints (such as Amazon EC2 instances, Application Load Balancers, Network Load Balancers, or Elastic IP addresses), and improves the latency, jitter, packet loss and throughput performance of your users’ traffic. Test the performance benefits from your own location with a speed comparison tool at https://speedtest.globalaccelerator.aws/.

Customers such as  8×8 and CrazyCall already use Global Accelerator to improve the user experience for their clients.

Using accelerators to improve call performance

Modern RTC architectures includes a number of key components that allow to establish voice and video live media sessions between participating parties. Figure 1 depicts a common deployment scenario, with Session Border Controller (SBC) along with Private Branch Exchange (PBX) and PSTN (Public Service Telephone Network) connections. In this scenario, local and transit Internet Service Providers (ISPs) carry VoIP traffic between the end users and SBC instances within an AWS Region. However, network performance such as latency, jitter, throughput over public internet is unpredictable.

Figure 1. Real Time Communication over the public Internet

Reliable and consistent performance for your VoIP traffic can be achieved by configuring AWS Global Accelerator between clients and your SBC instances (Figure 2). With AWS Global Accelerator, users benefit from better call quality, faster call setup time, and decreased call setup failure rate.

When you configure your RTC services to use an accelerator, you benefit from the vast, highly available, and congestion-free AWS global network.

Figure 2. Real Time Communication over AWS Global Accelerator

We ran experiments to quantify these improvements, which we describe in the next sections.

Improved VoIP call quality

To measure how using Global Accelerator improves VoIP call quality, we conducted a series of experiments. We configured the clients and endpoints (SBC) in AWS Region. We measured several metrics such as the end-to-end latency, packet loss, and jitter across two continents with and without Global Accelerator.

To understand the results of our experiments, you need to be familiar with the Mean Opinion Score (MOS). MOS is a common measurement used to determine the quality of customer call experience. ITU-T P.800.1 and P.800.2 recommendations define common terminology and interpretation for MOS results. The most frequently used scale is the following 5-point Absolute Category Rating (ACR) scale:

The maximum obtainable score for G.711 codec is 4.4. Average users are “Satisfied” with the quality of Real-Time communication if the MOS Score is in 4.0 to 4.3 range, and are and “Very Satisfied” if the score is equal to, or exceeds, 4.3.

Network conditions such as available bandwidth, network latency, jitter, and packet loss have a direct impact on the MOS Score. We used G.711 codec for our MOS calculation as this is one of common codecs for VoIP communication. However, you can choose other codecs that work for your use case.

In our experiments, we performed a number of experiments comparing MOS scores for RTC deployments with and without the Global Accelerator enabled. Our clients and servers were residing across multiple geographies including North America, Europe, and APAC regions.

For all experiments combined, the average observed MOS score improved from 4.26 (satisfied) with public internet to 4.35 (very satisfied) with Global Accelerator. The most significant improvement was observed for the RTC call between Australia and Germany, with the MOS score increasing from 3.17 with public internet to 4.32 with Global Accelerator. Our analysis revealed that the Internet path between two calling parties was experiencing the packet loss of ~11% without the Global Accelerator. This loss was eliminated by passing the traffic through the Global Accelerator. We encourage you to do your own experimentation and compare the results, as required geographies and Internet conditions of your deployment will likely be different from ours.

Improved call setup time and call setup success rate

We also performed an experiment to measure how Global Accelerator improves the call setup time and call setup success rate. These factors are also important in RTC applications and will impact the overall end-user experience. High latency and high packet loss negatively influence both of these parameters.

Session Initiation Protocol (SIP) is commonly used as a signalling protocol in VoIP RTC environments. With SIP, a typical call setup process includes a number of steps, as shown in the following diagram.

Figure 3. SIP Call Setup

By improving the end-to-end network latency and eliminating packet loss, Global Accelerator helps to decrease the time it takes to complete each call setup step.

In an experiment to verify the improvement effect of using Global Accelerator, we used the SIPp test tool (http://sipp.sourceforge.net/). Using the tool, we compared the average call setup time and call failure rates between the same two environments that we used to measure the MOS score in our earlier experiment.

We observed up to a 5x improvement in the call setup time and up to a 6% increase in the call setup success rate for packets that passed through the Global Accelerator. We attribute these improvements to the reduction in the end-to-end network latency, as well as the elimination of packet loss and retransmissions.

Now that you’ve been introduced to the benefits of running Global Accelerator in an RTC environment, we will walk you through Global Accelerator’s setup steps.

How to deploy an accelerator with an SBC

In this section, we show you how to build the environment using AWS Management. AWS Command Line Interface (CLI) configuration of accelerators and endpoints is also supported.

Step 1: Create a new accelerator

1.    Start by opening the Global Accelerator console at https://us-west-2.console.thinkwithwp.com/ec2/GlobalAccelerator/ and choosing Create accelerator.

2.     Provide a name for the accelerator, SBC-1, and then choose Next.

Step 2: Add TCP and UDP listeners

A listener in Global Accelerator processes inbound connections from your clients to Global Accelerator, based on the ports and protocols that you specify. Global Accelerator supports both TCP and UDP protocols. You define a listener when you create your accelerator. Configure your listener to listen to one, multiple or a range of ports. Listeners for different protocols such as TCP and UDP are able to send traffic to the same endpoints.

1.     On the Add listener page, enter the protocol for each listener, and the ports or port ranges to associate with each one. In our example, for the first listener, we specify TCP with ports 2000, 2443, 2445, 3804, 5060.

2.     To add the UDP listener, choose Add listener, specify UDP with ports 5060, 16384 – 32767, and then choose Next.

Step 3: Add an endpoint group

Next step is to add an endpoint group, which is associated with a specific AWS Region.

An endpoint group routes requests to one or more registered endpoints in AWS Global Accelerator. An endpoint group, and all the endpoints in it, must be in one AWS Region. If needed, add different endpoint groups for different purposes, for example, for blue/green deployment testing.

Global Accelerator directs traffic to endpoint groups based on the location of the client and the health of the endpoint group. When appropriate, set the percentage of traffic to send to an endpoint group. You do that by using the traffic dial to increase or decrease traffic to the group.

1.     On the Endpoint groups page, we select the AWS Region where the SBC instance is deployed. For our specific test scenario, SBC instance was deployed in the single AWS region, so, we left the Traffic dial setting at 100 directing all traffic to this AWS Region. However, if your SBC implementation supports multi-region setup, use the traffic dial to specify how much traffic goes to which AWS Region.

2.     Under Configure health checks, you configure health checks for the endpoints configure behind your accelerator. We specified the same TCP port, 2000, for health checks for both the TCP and UDP listeners. Start with configuring the port for the TCP listener, as shown in the following screenshot.

3.     Next, configure health checks for the UDP listener by pointing to the same TCP port, 2000, that was used for the TCP listener. Specify the port for the UDP listener as shown in the following screenshot, and then choose Next.

Step 4: Add endpoints

Now add the endpoints for the SBC, for both listeners.

1.     On the Create endpoints page, in each endpoint group for each listener, add an EC2 instance endpoint for SBC. For Endpoint type, we choose EC2 instance in the dropdown list.

2.     Leave the Weight settings at the default, and then choose Next.

Now Global Accelerator service begins creating the accelerator. On the dashboard, you’ll see a message that your accelerator is In Progress. When the process is finished, you will see the new accelerator with two static IP addresses in the Deployed state. Use these IP addresses to test connectivity to your SBC instance and measure RTC performance.

Testing RTC performance improvements over AWS Global Accelerator

Now that you have setup the AWS Global Accelerator, you can validate voice quality improvements associated with this deployment. Point the clients to newly allocated anycast IP addresses provided by the Global Accelerator and compare the quality of user experience. As an alternative, you can use voice quality measurement tools such as Ixia’s IxChariot from AWS Marketplace. You can also create synthetic tests using open source tools as described in the next sections.

Calculating MOS Score for your environment

Network conditions such as available bandwidth, network latency, jitter, and packet loss have a direct impact on the voice quality. In order to calculate the MOS score, we first need to measure the end-to-end network latency, jitter, and packet loss. This was done using a well-known open source iperf tool.

• Deploy iperf software on an EC2 instance running Linux in a desired AWS Region
• Start iperf server on the EC2 instance using the following command:

iperf -s -u -i 1

• On a Linux machine simulating a client device, install iperf and execute the test against one of Global Accelerator’s IP addresses:

iperf -c <Global Accelerator’s IP>   -u -l 218 -b 64K -i 1

Provided iperf parameters will simulate G.711 64 Kbit/sec data stream with 218 Bytes packets. The performance data that you will collect on iperf server includes latency, jitter, and packet loss measurements. If needed, simulate other codecs by adjusting bandwidth and packet size parameters using known bandwidth consumption information.

If G.711 codec is used, the MOS score for given conditions is calculated using the following formulas:

Using collected data and aforementioned formulas, calculate the MOS score for your environment.

Measuring call setup time and call failure rates

SIPp is a free Open Source test tool / traffic generator for the SIP protocol (http://sipp.sourceforge.net/). Using the tool, compare the average call setup time and call failure rates between an environment configured with AWS Global Accelerator to an environment without one.

In order to do the test, follow these steps:

• Deploy SIPp software on an EC2 instance running Linux in a desired AWS Region.
• Start sipp in the server mode on the EC2 instance using the following command:

sipp -sn uas

• On a Linux machine simulating a client device, install sipp, and then execute the following test against one of Global Accelerator’s public IP addresses:

sipp -i <local ip> -sn uac <Global Accelerator’s IP> -r 100 -m 100000

Running this command captures SIP-related performance statistics, including call rate, number of successful and failed calls, and number of retransmissions.

Conclusion

In this blog post, we provided the steps to set up AWS Global Accelerator with a session border controller to improve the user experience for real-time communications applications. We also shared our experiments that demonstrate how Global Accelerator improves the overall user experience by improving the call quality, decreasing the call setup time, and minimizing call setup failures.

Note that while we used SIP RTC for our measurements and experiments, AWS Global Accelerator delivers similar performance improvements for WebRTC sessions.

To get started, visit the AWS Global Accelerator website and review documentation.