A couple years back we purchased some HMP Enhanced G.729/G.723 licenses to reduce bandwidth use by our remote locations. Several months ago we discovered that G.729 was never utilized and all calls defaulted to G.711 despite settings in Regionalization indicating G.729 should be used before G.711. We were initially told this was a bug they were working on fixing. Now we've been told it is working as intended and our expectation that the codecs will be used in order of priority is unrealistic. The latest feedback from support is that "the list was never intended to be used as an ordered list and the system will always send G711 first if it's in the list then G729." Why then would the codecs be provided in list form with the heading Prioritized Codecs? Even the Regionalization and Dial Plan documentation states "If the gateway supports additional codecs, select them as well and use the Up and Down buttons to order the priority of codecs used". I know we're not the only ones using these licenses and would like some feedback on what others are experiencing as well as your expectations when you purchased them. We don't believe our expectations of the functionality should be considered an Enhancement request but that this flaw should instead be treated as a bug and addressed ASAP with an SCR. Any thoughts or feedback would be greatly appreciated! :)

To get more feedback: which IC version are you using? We don't experience any problems in 3.0 SU9 to get the codec priority list works as intended.

I'm very surprised to hear this and haven't noticed this behaviour at all. I'm though on the same version as ijimenez

Originally posted by ijimenez;19896
To get more feedback: which IC version are you using? We don't experience any problems in 3.0 SU9 to get the codec priority list works as intended.

My apologies for the delayed response...I wasn't receiving email notifications for this post. We're using 3.0 SU8...getting ready to move to SU10 next month.

Originally posted by jmcevoy;19894
The latest feedback from support is that "the list was never intended to be used as an ordered list and the system will always send G711 first if it's in the list then G729." Why then would the codecs be provided in list form with the heading Prioritized Codecs? Even the Regionalization and Dial Plan documentation states "If the gateway supports additional codecs, select them as well and use the Up and Down buttons to order the priority of codecs used".

Just to make this clear. When you said "latest feedback from support", are you meaning direct ININ support or your system integrator or reseller support?

It could be an issue with codec availabilty. The call won't be able to switch to G.729 if it isn't enabled on all the end points. Make sure that G.729 is enabled on your gateways. If the Gateways don't advertise that they are capable of that codec, it won't ever get used. We're using IC 3.0 SU6 with both Interaction Gateways and Audiocodes gateways, and G.729 works as we have it configured in the Regionilization settings. Just be aware that G.729 will affect your call quality. Also, when a call is on hold, it will be using G.711, as on hold music doesn't function properly on G.729.

Hi all, We experience a different problem here. When making calls using G.729, everything's fine during the call, but when listening to recordings, sound drops completely for either party or gets distorted beyond recognition. Same thing happens when supervisors listen to live calls via Interaction Supervisor. But again, there is no problem at all in the communication between the agent and the caller. Some background info: we're using IC 3.0 SU9 and SIP trunks (I know, not supported yet ;)) and G.729 is enabled on the router where the SIP trunks are connected. On the router we see that calls are actually established in G.729, and bandwidth usage decreases accordingly. Anybody any idea how G.719 could have a negative effect on recordings while actual calls are not affected? Thanks in advance.

Ok i'm not 100% sure but is your supervisor endpoint allowed to use the same codec as the 2 endpoints in the conversation? If not then how can the supervisor endpoint understand the current audio stream between the endpoints? And what is the Compression format the recorder is compressing the call with? None, True Speech or GSM 6.1? I would start looking on these two points and if I couldn't figgure it out from there, then I would open a case with support for this. I hope that helps you further.

Originally posted by heser;20058
Hi all, We experience a different problem here. When making calls using G.729, everything's fine during the call, but when listening to recordings, sound drops completely for either party or gets distorted beyond recognition. Same thing happens when supervisors listen to live calls via Interaction Supervisor. But again, there is no problem at all in the communication between the agent and the caller. Some background info: we're using IC 3.0 SU9 and SIP trunks (I know, not supported yet ;)) and G.729 is enabled on the router where the SIP trunks are connected. On the router we see that calls are actually established in G.729, and bandwidth usage decreases accordingly. Anybody any idea how G.719 could have a negative effect on recordings while actual calls are not affected? Thanks in advance.

Do you have Media Servers in the mix? Do you have multiple regions setup in your system? Is the voice dropout consistent, or intermittent? I would also look at getting some network traces. See if you can track down the tap for the call recordings, and listen to that. See if the dropout is happening on the network, or if it's somehow on the recorder server.

Originally posted by NiteOwls;20059
is your supervisor endpoint allowed to use the same codec as the 2 endpoints in the conversation?

Yes, the supervisor has the same codec.

Originally posted by pwatkins;20062
Do you have Media Servers in the mix? Do you have multiple regions setup in your system? Is the voice dropout consistent, or intermittent?

Yes, we do have a Media Server and voice dropout is intermittent. Regionalization settings are like this: [ATTACH]361[/ATTACH]

Originally posted by pwatkins;19906
It could be an issue with codec availabilty. The call won't be able to switch to G.729 if it isn't enabled on all the end points. Make sure that G.729 is enabled on your gateways. If the Gateways don't advertise that they are capable of that codec, it won't ever get used. We're using IC 3.0 SU6 with both Interaction Gateways and Audiocodes gateways, and G.729 works as we have it configured in the Regionilization settings. Just be aware that G.729 will affect your call quality. Also, when a call is on hold, it will be using G.711, as on hold music doesn't function properly on G.729.

Thank you Paul...this sounds promising. I'll do some additional research and see what comes of it. :)

I know this issue. It's not a bug. It's just the way how the ININ's TsServer was designed to work. I needed this functionality on one of my projects 3 years ago. The ININ Dev.Team told me that there were some problems they've encountered with offering multiple codec on SIP INVITE SDP messages. One of them was that remote party could change the codec say from G.711 to G.729 durring the call because we initially said that we support them. Since this type of change might cause resource, licensing etc. problems they decided to offer a single codec right from the begining of the conversation. The one that's checked on and on the top of the list. I also had similar codec advertising problems when 2 codecs were selected. And learned that I had to create a separate Region for lines/phones/devices using G.729 codec and select only that codec from the list. Everything works fine then. By the way having several codecs selected allows us to answer an incoming sip call requesting any of these codecs. This is why we need the this list. I requested this to be changed and have the ability to advertise all the codec on the list back 3 years ago but I haven't filled a SCR form. Finally it looks like we're getting this functionality with SU11 :) IC-77584 Offer multiple codecs if configured and if media servers are enabled. Adding "Offer Multiple Codecs" and setting it to "Yes" on a SIP line (through DSEdit) will cause TS to offer multiple codecs to the remote system. Regards, Oktay

Originally posted by ijimenez;19903
Just to make this clear. When you said "latest feedback from support", are you meaning direct ININ support or your system integrator or reseller support?

This is coming directly from ININ.

Originally posted by jmcevoy;19894
Several months ago we discovered that G.729 was never utilized and all calls defaulted to G.711 despite settings in Regionalization indicating G.729 should be used before G.711.

Where can I find informations, which codec is using for which call?