CM 10.5 // 6900 SCCP 9.4.1.3.SR2 // One-way Audio

[Jacob Webb]

Note:  These are all internal calls.  Nothing hitting the PSTN.

I am having a problem where my 6900 (6921 specifically) series phones are getting a weird problem when calling into a CCX line.  When the user calls they hear the greeting and then the hold music while they wait to be transferred.  Then you can see on the display that the call was taken by an agent, but the hold music continues to play and no audio is received from the CCX agent.  The agent reports that they can hear us.  When the agent calls the phone back, the audio works fine.

I noticed that this is working correctly on SCCP firmware version 9.4.1.3.SR1, but not on 9.4.1.3.SR2.  I upgraded to SR2 because of the directory problem.

Any thoughts?

[Manish Gogna]

If you can reproduce the issue by using firmware 9.4.1.3 Sr2 and it goes away when downgraded to 9.4.1.3 Sr1 then this could be a bug. You may check this with TAC if this is a known issue and if any firmware is available with a fix.

Manish

[Jacob Webb]

I opened a case with TAC and they found a problem with this firmware and multicast MOH.  By switching to unicast MOH the problem goes away.

My last update from TAC is that this is an undocumented defect and has been escalated.

[michaelfine77]

Do you have the bug ID as we appear to be having the same issue with 6941 phones. An internal call to phone works, when call is placed on hold MOH is heard, when call is taken off hold, one way audio.

Issue is new after upgrading from 10.5.2su2 to 10.5.2su3

Thanks

Michael

[pkinane]

Hello Michael,

It sounds like your issue is different. It would likely be best to open a new thread with the specifics of your issue (upgrade details, firmware version on the phone, and some logs from the CUCM).

If you do open a new thread and gather the logs, here is I suggest doing:

First make sure you "set the service parameter 'Digit Analysis Complexity' to 'TranslationAndAlternatePatternAnalysis' prior collecting the trace" as suggested by venperum.

Then make a call, have the call connected for about 30 seconds, then place the call on hold, keep it on hold for about thirty seconds, take the call off hold and let it stay connected for 2 minutes or so to see if the call will terminate on it's own (otherwise we may see cause code 16 which is normal call clearing).

Document the calling number, the called number and the start time of the call then attach the logs to your thread.

The example in the document shows to use the absolute range for date and time; however, I recommend using the relative range option for selecting the time to pull the traces rather than using the absolute range due to the fact you can reproduce this at will.

https://supportforums.cisco.com/document/126666/collecting-cucm-traces-cucm-862-tac-sr

[pkinane]

Michael,

I looked up the TAC case. No defect was filed because the 69xx phones are beyond their software maintenance.

[Stefan Walter]

Hi,

Can you reproduce the issue with one of the affected phones and send us a wireshark capture of one of the affected phones?

Please enable the span to pc port on cucm side before you do a capture.

Thanks,

Stefan