Double Talk question

jbillingsley · ‎09-02-2010

Hi All,

I've had complaints from users where they are not experiencing "full duplex" while on a call with the PSTN. The call is going through a 2821 H323 gateway running 12.4(15)T14.

When both the local and remote callers are speaking at the same time, the local user can't hear anything the remote user is saying. So the external user can't interject or correct something the local user said b/c the local user never hears it. This doesn't seem like such a big problem at first, but this also occurs when there is any background noise on the local caller side. It will cause the audio from the external caller to break-up.If you test this between two IP Phones, this problem does not exist.

Does anyone know of this problem or a way to alleviate it. I have read the details for CSCsq80574 and it seems to fit what I'm running into, but it doesn't look like Cisco is too keen on fixing this bug since it has exisited in all of the recent versions of code. I even rolled back to 12.4(15) and it still seems to exist.

Regards

Steven Holl · ‎09-02-2010

CSCsq80574 was fixed in 12.4(15)T9.

First, whose side is it that is missing audio? Is it the IP phone, or the PSTN side? (You use the terms local and remote, which are vague.) Our ECAN only takes effect on audio in from the PSTN, so if the PSTN user is the side that is hearing missing audio, it's likely not an issue on the Cisco side.

Make sure you're not on speaker phone, and that VAD is disabled, too.

You probably want to open a TAC case to get this looked at in more detail, though. You can have TAC obtain a PCM capture off the DSP and find out if it is the Cisco ECAN/NLP which is being to agressive and removing the speech, or if the issue is coming upstream. If our DSP is at fault, the audio will be in Sin, but not in Sout.

I know there is a known issue with this for LSI DSPs (CSCth60636), but you aren't on that DSP platform, so that's irrelevant.

I actually am currently working a simliar issue with a customer regarding this on 5510 DSPs right now, actually. Current troubleshooting has pointed that the provider's DSP is actually the one chopping the audio out. We've scheduled a third party audio capture to be done on the T1 in stream, just to make sure we can trust the results of the PCM capture. If you reply to this thread on Monday, I will be glad to share the results, in case I do find something on our side. But for my scenario, I've got fair confidence it is an upstream issue.

-Steve Holl

jbillingsley · ‎09-02-2010

Steven,

Thanks for the details!

Sorry for not clarifying. It is the IP Phone user that is experiencing the missing audio. We are not on speaker phone and vad is disabled. I have had a TAC case open and so far they've just suggested moving IOS and seeing if the problem goes away, there is no real troubleshooting happening from their side. I will get a PCM capture and have them analyze it, that's a good suggestion by you. We are also using 5510 DSPs.

Please update me on what you find with the other customer you're working with. The aspect that makes me think this is not an upstream issue is the fact that we tested with a regular analog phone and did not experience this. We are, of course, using POTS lines and not a T1.

Thanks,

Jake

Steven Holl · ‎09-02-2010

Jake,

Can you PM me the TAC SR number for this? I'd like to check it out and give guidance if necessary.

Since you are in an analog environment, it's a little different from my scenario (my customer had a T1 with the provider's ECAN on, so there isn't any echo at our DSP). Your analog run is almost surely going to exhibit some sort of echo at the FXO port, I'd imagine, and that may be enough of a difference for our root causes to not be the same.

The nice thing about the FXO port, is that if you are willing to spend $25 at radio shack, you can get an inline audio capture before the audio hits the Cisco DSP and rule out if the issue is at the gateway or not:

http://www.radioshack.com/product/index.jsp?productId=2062697

If that or the PCM capture point to an issue at the Cisco DSP, then we can invoke development and discuss other things such as tuning the ECAN/NLP for your environment.

Some things you may want to just go ahead and try, if you are willing, though:

* Make sure you don't have positive input gain applied to the voice-port. Default or negative values are ideal for optimal ERL settings on the ECAN.

* May be worthwhile to make sure you have the analog line's impedance set to the right value. You can run a THL sweep to determine this, unless you know the physical length of the provider's loop (http://www.cisco.com/en/US/partner/tech/tk652/tk701/technologies_tech_note09186a0080477a06.shtml)

* Configure 'echo-cancel mode 2' under the voice-port and shut/no shut the port. This mode is supposed to handle double talk scenarios better, if it does end up being an issue on our ECAN.

* You can try disabling NLP with 'no non-linear' under the voice-port. Shut/no shut to take effect. You may notice adverse effects to the voice calls when doing this, so it is something to test out and get a response on.