OfficeLinx + CS1000 - Poor quality sounding messages

[SherWat]

CS1000 7.6
OfficeLinx (1X Messaging) at 10.6
Using 1230, 1220, 1120 and 1140 IP phones

For some of our voice mail boxes, when messages are left, they are very poor quality and often sound as though the caller is drunk. I have attached a wave file of what it sounds like.
I am having difficulty in troubleshooting this issue, since it isn't happening for every voice mail box, nor does it happen for every message left in the mailboxes that have experienced this issue.
I have deleted the voice mail boxes and recreated it - problem still exists.
I have rebooted the VOIP phones that have the extension number of the mailbox - problem still exists.

Here is a trace of when I logged into my voice mail and tried to record my mailbox greeting which, when played back, sounded like the attached message.

.trac 248 0 0 8

VTN 248 0 00 08
KEY 0 MCR MARP ACTIVE VTN 248 0 00 08

ORIG VTN 248 0 00 08 KEY 0 MCR MARP CUST 0 DN 2500 TYPE 1230
SIGNALLING ENCRYPTION: INSEC
FAR-END H.323 SIGNALLING IP: 10.35.1.15
FAR-END MEDIA ENDPOINT IP: 10.35.5.214 PORT: 5200
FAR-END H.323 SIGNALLING IP: 10.35.1.15
FAR-END MEDIA ENDPOINT IP: 10.35.5.214 PORT: 5200
TERM VTN 148 0 00 11 VTRK IPTI RMBR 2 12 OUTGOING VOIP GW CALL
FAR-END SIP SIGNALLING IP: 10.30.10.101
FAR-END MEDIA ENDPOINT IP: 10.30.10.101 PORT: 20032
FAR-END VendorID: UA-TOLEE-10.5
MEDIA PROFILE: CODEC G.711 MU-LAW PAYLOAD 20 ms VAD OFF
RFC2833: RXPT 101 TXPT 101 DIAL DN 70002500#
MAIN_PM ESTD
TALKSLOT ORIG 13 TERM 18 JUNCTOR ORIG0 TERM0
QUEU NONE
CALL ID 300 4322
​

Has anyone heard of a similar issue?
Thanks everyone.

 

[biv343]

I ran into a very similar issue. In OL admin, check the feature group(s) on the general tab and make sure the message format is set to ULAW8.

It looks like OL wants to default to ALAW at times, or at least when adding a new feature group.

 

[SherWat]

Thanks for the suggestion. I checked all my feature groups and they were all set to ULAW8.

 

[biv343]

It may be worth running Wireshark on the voice server, make a test call and gather a packet capture, then play back the audio stream in Wireshark. That could help narrow down if the server is recording what it is receiving (potential network issue), or if potentially there is a server issue such as high CPU utilization, disk I/O or other resource constraints.