Recording sounds garbled on playback

[cherith.law]

I have a customer who is using QM to do their call recordings. Recordings are done at the desktop end, and transferred to the server nightly. The problem they are experiencing when the supervisor plays back a recording from the day before, about 1 in 10 recordings sound garbled. The problem with recording quality always happens after an internal transfer to another agent.

For instance, an external caller talking to agent1 will sound perfectly fine. But when agent1 puts the caller on hold, and speak to agent2, the recording of both agent1 and agent2 degrades (similar to stuttering). When agent1 resumes call with caller again, the stuttering continues, with audio from caller being heard with a few seconds delay in response to agent1.

They've had the QM installed abt 2-3 years ago, but issue only started happening 9 months ago. The issue is random, happens to some agents, and the time of recording is scattered throughout the day.

Their LAN is very straight-forward, with separate vlans for voice and data. No SPAN/RSPAN is used. Agents are connected to various floor switches, which connects back to the core switch where the QM server, UCCX, CUCM, etc are connected to. All agents use IP handsets 7941 which is daisy-chained to their computers.

Any ideas of where I can start looking into the issue?

[Nisar Ahamad]

Did you happend to get any work around for this. I am facing same issue with o

ne of our client where in recording play back for the internal calls sound garbled.

[cherith.law]

Hi Nisaar,

No, I haven't found the cause for this recording quality issue yet. The problem happens not just on call transfers, it sometimes happens on calls from an external number, or internal calls. The IP phone makes a copy of the RTP and sends it on to the PC which is daisy-chained. The issue also happens when playback is direct from the PC on the day of recording, prior to transfer to the server. Therefore I can't see what can affect the recording other than the phone switchport, the ethernet cable between phone and PC, and the PC itself.

I tried replicating the issue by making calls with high CPU usage and high network utilization, but was not able to replicate it. I've also checked phone settings, and it has audio packets marked with CS3 tags, and NIC has flow control enabled and priority&vlan enabled. I've gone through sqm logs and the recordings are marked for quality and archiving. I don't know where else to look.

[Live2 Bicycle]

I had an issue similar.  Fought it for about a month.  It ended up being a timing issue between my UCM 7.1.2 servers and my Cisco 3845 voice gateways.  The gateways are MGCP controlled.

A simple no mgcp then waiting a couple of seconds then mgcp on the 3845 fixed it.

I still dont fully understand the issue but I know it resolved it.

HTH

Del

[cherith.law]

Hi Del

That's a fair point! Unfortunately I can't see how my problem can be related to the timing/sync issue as the call was internal and does not traverse the gateway.

Cherith

[Nathan Luk]

Hi Cherith,

Do I know you from a previous life? Your name seems really familiar. I was ex-Touchbase...

Anyway, I haven't seen it with QM in particular but I have with Verint in that it wasn't coping with codec changes mid-call specifically from u-law to a-law. The client I was working with used a SIP carrier calls came in external as a-law and when they were on a consult leg with another agent the codec negotiated between the handsets was u-law and when the recording tended to have issues when the codec switched but only specifically with G711 and a-law to u-law. So codecs might be another thing to look at.

Cheers,

Nathan

[Nathan Luk]

Also, is it easily reproducible with transfer scenarios? If it is, another thing you could try test is take QM out of the picture, do a recording through CAD and use the Raw2Wav tool to convert it and try play it back.

[cherith.law]

Hi Nathan,

I do know you from previous life! Must have been at least 4-5 years ago ... good memory!!

I have, so far, not considered codec changes because the issue was happening on internal calls. But on checking the logs, I've realised that the agent was calling another agent by dialling the route point, and that a transfer was involved. I will defintely check on codec changes now and let you know how I go.

Cherith