Codecs play an important role in our smartphones. Not only are they necessary and must for encoding/decoding the voice packets but they increase the price of our smartphones too.
A $400 smartphone can have as much as $120 in IPR fees. If you notice in the picture above its $10.60 for the H.264 codec. So its important that the new codecs that will come as part of new generation of mobile technology is free, open source or costs very little.
The new standards require a lot of codecs, some for backward compatibility but this can significantly increase the costs. Its important to make sure the new codecs selected are royalty-free or free license.
The focus of this post is a presentation by Amir Zmora from AudioCodecs in the LTE Voice Summit. The presentation below may not be self-explanatory but I have added couple of links at the bottom of the post where he has shared his thoughts. Its worth a read.
A good explanation of Voice enhancement tools as follows (slide 15):
Adaptive Jitter Buffer (AJB) – 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.
Further reading:
The new standards require a lot of codecs, some for backward compatibility but this can significantly increase the costs. Its important to make sure the new codecs selected are royalty-free or free license.
The focus of this post is a presentation by Amir Zmora from AudioCodecs in the LTE Voice Summit. The presentation below may not be self-explanatory but I have added couple of links at the bottom of the post where he has shared his thoughts. Its worth a read.
A good explanation of Voice enhancement tools as follows (slide 15):
Adaptive Jitter Buffer (AJB) – 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.
