It has been ages since we have added the G.726 codec. This codec has some features that are quite favorable for a PBX: First of all it typically runs on 32 kbit/s, which translates into a data rate on the cable of 56 kbit/s if you include the overhead for the RTP and IP headers. It also has a relatively low CPU overhead, at least compared to heavyweights like OPUS or speex. You have to keep in mind that the PBX potentially have to run many calls with that codec, in contrast to endpoints that usually run only one call. Thus the CPU overhead is much more important for a PBX than for the endpoint.
G.726 is not exactly the best codec for music on hold, but at least performs better than codecs that compress voice a lot more like G.729 or G.723. This is also no big surprise if you think about it; if you take a lot of bits out of the media stream, it is only the voice that is left over and other things like drums and trumpets don’t make it. Because the G.726 model is quite simple, it does not really differentiate between voice and music.
G.726 is widely deployed in DECT digital cordless telephones. But also in the VoIP world, G726 is available in many devices. A quick research shows that at least snom, Yealink, Linksys SPA and also Grandstream support it.
Anyway, it was time to review the support for this codec also on the PBX. The IETF has originally specified a hardcoded codec type 2 for G.726, probably in anticipation that this codec would be very popular. However there were problems with the “bit-sex” representation. The ITU was using a different representation that the IETF, which lead to a quite a chaos getting this codec working between the different devices. We also did take a 2nd look and decided to drop the hardcoded codec number and instead choose a dynamic codec number. That seems to work well with most devices. Version 5.1.3 will re-introduce G.726 and we hope that those who have limited bandwidth with consider this codec again.
.svg)
