QoS (Quality of Service) is a major issue in VoIP implementations. The issue is how to guarantee that packet traffic for a voice or other media connection will not be delayed or dropped due to interference from other lower priority traffic.
For the end-user, Packet loss causes interrupt. Some degree of packet loss will not be noticeable, but lots of packet loss will make sound lousy that is why VoIP is not tolerant of packet loss. Even 1% packet loss can “significantly degrade” a VoIP call using a G.711 codec for example, and other more compressing codecs can tolerate even less packet loss.
This specific document will introduce and focus on the QoS considerations that have been added to the UCM630x series when handling audio and video calls.
Audio Packet Loss Improvement
UCM630x series have added different QoS settings that can help to improve the quality of service for Audio Calls, please refer to the following paragraphs in order to learn how to build and improve the quality of service in your audio calls.
FEC for OPUS Codec
OPUS codec has built-in inband forward error correction (FEC), mitigating the effects of packet loss.
It’s a capability that some systems employ to help mitigate errors when unstable transmissions occur. While implementation and handling algorithms can differ, an Opus encoder can embed redundant data about the preceding packet in-band in the current packet. This extra information can be crucial on the receiving side when a packet has been lost. For instance, when a packet of audio has been dropped an Opus decoder can rebuild that lost packet from the FEC data it obtains in the next packet it receives. This of course can help alleviate gaps in the audio stream.
The OPUS codec can be set for Internal calls on the extensions, to do so please go under Web GUI🡪Extensions/Trunk🡪 Extension🡪 Media and select OPUS Codec as Preference.
For external calls, the OPUS codec can be set on the trunk, to do so please go under Web GUI🡪Extensions/Trunk🡪 VoIP Trunks 🡪 Trunk🡪 Advanced settings and select OPUS Codec as Preference.
NetEQ
NetEQ is a dynamic jitter buffer and error concealment algorithm used for hiding the negative effects of network jitter and packet loss. It helps keep latency as low as possible while maintaining the highest voice quality.
For example:
Assuming there is packet loss between endpoint A and UCM, and there is no packet loss between UCM and endpoint B, after NetEQ is enabled on UCM for extension A, UCM can mitigate the effects of packet loss on the audio received from A and maintain audio quality when sending packets to B.
However, if UCM is sending audio to A, and packet loss is present, endpoint A will need to handle that packet loss on its own.
NetEQ is used in WebRTC for audio QoS purposes. As such, UCM’s Grandstream Wave, which uses WebRTC, comes with NetEQ support.
To reduce the effects of packet loss on audio received by the UCM on internal calls please go to Web GUI🡪Extensions/Trunk🡪 Extension🡪 Media
For External calls, please go under Web GUI🡪Extensions/Trunk🡪 VoIP Trunks
Audio GS-FEC
GS-FEC is a proprietary algorithm developed by Grandstream to minimize the effects of audio/video packet loss and can handle up to 50% packet loss in audio. This option is also available in the web portals of supported Grandstream product models.
The option can be set for each extension under Web GUI🡪Extensions/Trunk🡪 Extension🡪 Media
Video Packet Loss Improvement
In addition to Audio improvements, the UCM630x series have also added different QoS settings that can help to improve the quality of service for Video Calls. Please refer to the following paragraphs in order to learn how to improve the quality of the video calls.
Video GS-FEC
GS-FEC is a proprietary algorithm developed by Grandstream to minimize the effects of audio/video packet loss. This option is also available in the web portals of supported Grandstream product models.
To configure this feature, please go under Web GUI🡪Extensions/Trunk🡪 Extension🡪 Media
NACK
NACK or negative acknowledgment is one of the QOS methods to improve the reliability of retransmission for the video to combat packet loss.
By enabling negative-acknowledgment (NACK), the UCM will retransmit packets that have been lost in the initial transmission to repair the media stream.
In order to activate this feature, please go under Web GUI🡪Extensions/Trunk🡪 Extension🡪 Media and set the option “Packet loss Retransmission” to “NACK”.
NACK+RTX
RTX stands for retransmission. It’s a mechanism based on NACK, which means it relies on RTCP packets to find out which packets are lost first. For NACK, it will retransmit based on the original packet. With RTX, a special payload is used to retransmit the packets that a NACK request indicated as lost. Retransmitted packets are sent in a different stream from the original media stream. The payload of the retransmission packet contains the payload header of the retransmission followed by the payload of the original packet. RTX retransmits using an extra SSRC, which will be marked in SDP during negotiation.
RTX achieves similar packet loss performance compared to NACK. However, RTX provides more accurate packet loss statistics.
To enable this option on the UCM, please go under Web GUI🡪Extensions/Trunk🡪 Extension🡪 Media and set the option “Packet loss Retransmission” to “NACK+RTX(SSRC-GROUP)”.
QoS and Compatibility with Endpoints
Currently, NetEQ will take effect for received packets as long as it is enabled on the UCM. All other options mentioned previously require both the UCM and the endpoints to support and enable them.
Please find below the options requiring end point support:
Options | OPUS | NetEQ | Audio GS-FEC | Video FEC | NACK | NACK+RTX |
Require end device support and negotiation | Yes | No | Yes | Yes | Yes | Yes |
