G.729 is a speech coder that has been around for more than 20 years, and was created at a time when a single call over the internet could consume most, if not all, of one’s available bandwidth. Hence the creation of speech coders, such as G729, that were able to preserve speech quality while lowering the consumption of limited bandwidth. Years later, the internet has progressed significantly, with private use bandwidth allocations exponentially exceeding even the requirements for large bandwidth codecs such as G.711.
However, this is not to say that lowbandwidth coders have outlived their use. A few applications exist today where their use is of paramount importance, such as conference calls, international/satellite calls, and most importantly, cellular communication. The necessity of the G.729 coder may be obvious in all of the aforementioned situations except for cellular, which is discussed further in the following text.
The main difference between in-home and cellular data connection does not lie with their speeds, both are comparable and both can handle large bandwidth VOIP codecs, but rather that while your in-home internet is likely unlimited, your cellular data is extremely limited and often very expensive per data unit. Thus it is advantageous that VOIP cellular communication be as bandwidth conscious as possible. In addition, as android/iOS and cellphone hardware inevitably improves, the apps available will also get more complex, shifting their primary form of communication between users from text to voice communication.
It is important to now point out why G729 has low bandwidth consumption, and to show that where it is smaller in size, it does not gain that at the cost of lower quality. In every instance of low bandwidth codecs we can note that at some point, we have to sacrifice the data points that we are sending out, as this has a direct relationship with bandwidth. G729 takes in samples at 8kbps, and for all intensive purposes has a 1 byte to 1ms ratio. At this point it is important to point out that other low bandwidth codecs exist such as G723.1 which will compress the audio even further (0.8byte/ms), however this is leaving out one key factor.
When using RTP to transport the audio we are receiving, through UDP, we have to add the size of the headers for RTP, UDP, and IP into each packet of data we are sending. When added up, the size of all of the headers on a single packet amounts to 40bytes (see diagram above), a considerable sum when size is our limiting factor. In this, the difference between G729 and G723.1 can be seen the most, as both have to incorporate the header into each packet. Thus, even though we are saving space with G723.1, when all is totaled together we are looking at a negligible bitrate difference for the greater sampling loss that G723.1 incorporates. In conclusion, the quality gained by using G729 is greater than the minimal space saved by using G723.1.
The last point is how low bandwidth codecs deal with the inevitable nature of UDP – packet loss. Due to the real time operation of VOIP, retransmission of lost packets and/or acknowledgement of received packets are out of the question, thus functions that can make up for gaps in audio are required. Two of the main ways to accomplish this are packet loss concealment, (PLC) and linear predictive coding (LPC). These methods give the end user the ability to predict future packets based on previously received packets, allowing an albeit imperfect, but rather robust method to fill the gaps. In any practical sense, these methods fill such a short gap of time, that the user should not notice when packet loss occurs.