eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I recently brought Polycom’s SoundPoint IP 550 and 650 phones into the lab as part of a wider look at the benefits of high-definition VOIP (voice over IP). Although the G.722 codec Polycom uses to achieve HD Voice is not widely supported at this time, Polycom promised that the open-source Asterisk project would support it, so I decided to see exactly what it would take to get the technology up and working with our in-house Asterisk deployment.
Starting with Version 1.4, Asterisk supported the G.722 codec in passthrough mode only. This means that Asterisk can set up a G.722-enabled call between two endpoints that support the codec and then get out of the way, but the server cannot transcode the streams between different codecs for devices with mismatched support. And while Polycom officials are investigating adding support for other wideband codecs, G.722 is the only one supported at this time.
To enable G.722 in Asterisk (our server is based on Version 1.4.9), I simply needed to add a single line to the sip.conf configuration file (allow=g722). I then had to configure each Polycom phone with G.722 as the codec with first priority. With these changes in place, I could place calls between my SoundPoint IP 550 and 650 devices and experience all the audio quality I expected from HD Voice.
However, interoperability with legacy devices was another story. While I could place calls from a non-HD Polycom SoundStation conference phone to an HD Voice-enabled phone using G.711, I could not complete a call in the reverse direction. The Asterisk server would show an error indicating congestion on the server, and the caller would experience a fast busy signal.
It turns out that Asterisk 1.4 cannot handle the codec negotiation necessary to complete the call between an initiating caller with priority for G.722 and a receiving caller with priority for another codec. “Asterisk’s codec negotiations currently treat the call legs independently, and thus never renegotiate the initial call leg based on the requirements of the secondary call legs,” said Digium Director of Software Development Kevin Fleming.
Asterisk users can look to the bleeding edge for a resolution. “In the Asterisk SVN trunk, we have a G.722 codec module, so this problem would not occur, and we’ll be putting that module into ABE [Asterisk Business Edition] as well,” Fleming said. “We may also put it into future s800i [Asterisk Appliance] builds.”
In my communications with Polycom about this issue, I learned that the company has achieved expected codec negotiations when using an SVN trunk of Asterisk. While this feature will likely not be part of Asterisk Version 1.4, users should be able to look forward to full support in Version 1.6 down the road.
