The Brain behind Voice Quality

Amir Zmora, VP Alliances and Partnerships for AudioCodes.

This post is by Amir Zmora, VP Alliances and Partnerships, AudioCodes, and Barry Spielman, head of Analyst Relations, AudioCodes

 Voice quality is a topic anyone dealing with VoIP knows is important and complex. Regardless if your expertise is on the client or server side, if your product is touching the media, you know that this requires constant work as there is always something to improve.

When calls traverse between different types of networks, things can get tricky due to the different network characteristics and the need to mitigate these differences. This issue will be the focus on my presentation at the upcoming LTE Voice Summit in London. I also covered it in detail in my post 3 Things Required for Managing Cross Network Voice Quality.

In this post, I want to talk about the voice enhancement tools available, those tools that would run and be dynamically utilized in the core network element, the “brain” of voice enhancement as I described it in that post.  So I highly recommend that you read that post for the sake of completeness of information.

Why cross network calls are tricky?

Network characteristics differ in jitter, reliability and design. Moreover, devices are typically tuned to work for different network requirements; a device that was built for wireline networks is tuned differently than one built for a wireless network.

As an example, a jitter buffer of an Enterprise IP Phone would be different from one of a mobile soft client. Codecs used by these clients would also typically be different.

The “brain” mentioned above would be the entity that mitigates these network differences using voice call enhancement tools. There are several tools available, below is a good summary of this by my colleague Barry Spielman.

Voice call enhancement tools

Adaptive Jitter Buffer – Almost all devices today (Smartphones, IP phones, gateways, etc.) have built in jitter buffers. Legacy networks (which were LAN focused when designed) usually have older devices with less sophisticated jitter buffers. When designed they didn’t take into account traffic coming in from networks such as Wi-Fi with its frequent retransmissions and 3G with its limited bandwidth, in which the jitter levels are higher than those in wireline networks. Jitter buffers that may have been planned for, say, dozens of msec may now have to deal with peaks of hundreds of msec. Generally, if the SBC has nothing to mediate (assume the codecs are the same and the Ptime is the same on both ends) it just forwards the packets. But the unexpected jitter coming from the wireless network as described above, requires the AJB to take action. And even if the network is well designed to handle jitter, today’s OTT applications via Smart Phones add yet another variable to the equation. There are hundreds of such devices out there, and the audio interfaces of these devices (especially those of the Android phones) create jitter that is passed into the network. For these situations, too, the AJB is necessary.

To overcome this issue, there is a need for a highly advanced Adaptive Jitter Buffer (AJB) built into the SBC that neutralizes the incoming jitter so that it is handled without problem on the other side. The AJB can handle high and variable jitter rates.

Additionally, the AJB needs to work in what is called Tandem scenarios where the incoming and outgoing codec is the same. This scenario requires an efficient solution that will minimize the added delay. AudioCodes has built and patented solutions supporting this scenario.

Transcoding – While the description above discussed the ability to bypass the need to perform transcoding in the Adaptive Jitter Buffer context, there may very well be a need for transcoding between the incoming and outgoing packet streams. Beyond being able to mediate between different codecs on the different networks on either end of the SBC, the SBC can transcode an incoming codec that is less resilient to packet loss (such as narrowband G.729 or wideband G.722) to a more resilient codec (such as Opus). By transcoding to a more resilient codec, the SBC can lower the effects of packet loss. Transcoding can also lower the bandwidth on the network. Additionally, the SBC can transcode from narrowband (8Khz) to wideband (16Khz) (and vice versa) as well as wideband transcoding, where both endpoints support wideband codecs but are not using the same ones. For example, a wireless network may be using the AMR wideband codec while the wireline network on the other side may be using Opus. Had it not been for the SBC, these two networks would have negotiated a common narrowband codec.

Flexible RTP Redundancy – The SBC can also use RTP redundancy in which voice packets are sent several times to ensure they are received. Redundancy is used to balance networks which are characterized by high packet loss burst. While reducing the effect of packet loss, Redundancy increases the bandwidth (and delay). There are ways to get around this bandwidth issue that are supported by the SBC. One way is by sending only partial packet information (not fully redundant packets). The decoder on the receiving side will know how to handle the partial information. This process is called Forward Error Correction (FEC).

Transrating – Transrating is the process of having more voice payload ‘packed’ into a single RTP packet by increasing the packet intervals, thus changing the Packetization Time or Ptime. Ptime is the time represented by the compression of the voice signals into packets, generally at 20 msec intervals. In combining the payloads of two or more packets into one, the Transrating process causes a reduction in the overhead of the IP headers, lowering the bandwidth and reducing the stress on the CPU resources, however, it increases delay. It thus can be used not only to mediate between two end devices using different Ptimes, but also as a means of balancing the network by reducing bandwidth and reducing CPU pressure during traffic peaks.

Quality-based Routing – Another tool used by the SBC is Quality-based routing. The SBC, which is monitoring all the calls on the network all the time, can decide (based on pre-defined thresholds and parameters) to reroute calls over different links that have better quality.

 

Putting it all together

The above built-in SBC capabilities provide a powerful arsenal for combatting the ill effects of Jitter, delay and packet loss. Each tool on its own can play a major role in significantly enhancing QoE. The SBCs run a real-time algorithm that measures these parameters on every call. If one or more thresholds are crossed, the SBC can activate any of the above-mentioned quality enhancement tools. The SBC knows how each change in each parameter can effect voice quality and it knows how much needs to be changed in each parameter to maximize the voice quality.

 

Bio

Amir Zmora (@AmirZmora) is VP Alliances & Partnerships for AudioCodes. In his current role, Amir is heading technical and business alliances as well as new technology initiatives and new media.  Amir is presents regularly at industry conferences and tradeshows. In addition to the AudioCodes Voice blog, Amir publishes on other blogs such as NoJitter, UC Strategiesand BlogGeek.me

Barry Spielman joined the AudioCodes team in December 2013 after working many years in the telecommunications field in hi-tech companies such as RAD Commucations, Gilat Satellite Networks and Verint Systems. In his current capacity, Barry heads AudioCodes’ Analyst Relations and spearheads a variety of marketing programs. Barry is a Lt. Col. In the army reserves having served for an extended period in military public affairs in the IDF. He holds Masters Degrees in National Security Studies from George Washington University and Business Administration from Boston University.