It has been ages since we have added the G.726 codec. This codec has some features quite favorable for a PBX: 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 the PBX potentially has to run many calls with that codec, in contrast with 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 it 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's only the voice that's left over, and other things like drums and trumpets don’t make it. Because the G.726 model is quite simple, it doesn't really differentiate between voice and music.
G.726 is widely deployed in DECT digital cordless telephones, but in the VoIP world it's available in many devices. Quick research shows at least snom, Yealink, Linksys SPA, and also Grandstream support it.
Anyway, it was time to review the support for this codec on the PBX. The IETF originally specified a hardcoded codec type 2 for G.726, probably in anticipation this codec would be very popular. There were problems with the “bit-sex” representation, however; the ITU was using a different representation than the IETF, which lead to quite a lot of chaos getting this codec working between the different devices. We also did take a second look and decided to drop the hardcoded codec number and instead choose a dynamic codec number; this seems to work well with most devices. Version 5.1.3 will re-introduce G.726, and we hope those with limited bandwidth with consider this codec again.
.svg)
