Message recording quality sounds like the person is underwater. This has occured in the last two weeks. We have been making changes to the WAN QoS, but only significant improvements in voice calls across the WAN have resulted, so I can't image that would be the cause.
The first time this happened we reset Unity and the problem seemed to go away, but we're not entirely sure. At any rate, the problem definitely resurfaced 3 or 4 days later. (The reset may not have done anything as the users can't give a definite time as when this happened).
This does not happen on every call. Because most of their callers who leave messages come from the PSTN, we don't know the ratio of band internal messages to bad external messages.
We are running Call Manager 3.2.2spE. Unity 3.1.5
The topology is thus: PSTN via PRI to VG200 to phones. If call goes to voicemail here is the path: PSTN via PRI to VG200 to router across 786k Frame Relay WAN link to VG200 transcoder/DSP Farm to Unity.
As you can image, G.729 across the WAN, transcoded by the DSP farm to G.711, then to Unity. The DSP farm has never seemed to be an issue, though it isn't ruled out yet.
512 MB of RAM on Unity, it is serving under 50 people. It is also running Active Directory.
What's the record format on Unity? You can check with SetRecordFormat.exe. Even though it's intermittent, can it be reproduced? Does the entire recorded message sound bad, or just portions? Do prompts ever sound bad?
8.000 kHz, 8 bit, mono, 7 kb/sec
I haven't been able to reproduce it yet, but I will try over the weekend. The whole message sounds bad. There have been no reports of prompts sounding bad.
It looks like the whole conversation sounds bad. We were able to duplicate the problem with multiple mailboxes, and on messages left from a phone that is an ip phone and does NOT use the transcoder (g.711 to Unity), and on messages that use the transcoder and originate from the pstn.
Any further ideas?
I think the best (but not the easiest) thing to do would be to listen to the audio right before it hits Unity and right after it leaves Unity. This will require a sniff of the Unity switch port (span it) while running a capture when reproducing the problem. The RTP data can actually be generated into a wav file with some utilities that TAC has access to. It's the only way I know to see if the audio is bad before it hits Unity or if the audio is bad leaving Unity.
For anyone that's familiar with CSCdx36894, we got to root cause from a network capture done in the same manner described above.
Yes, I've thought of that. I wanted to keep Unity speaking G.711 to certain regions.
Of course, if the dsp farm doesn't work then we can certainly throw that out but I want pursue other possibilities first.
We are having a similar problem, with almost the same equipment. Although the BU had advised us that transcoding the Unity wasn't advised on 3.1.3a.
If you turn on G729 Unity will still use G711 with endpoints that support it. There is really no downside to allowing G729 on the Unity server.