Definitely two issues that have sort of separate troubleshooting steps. In general:
- is this an NM-CUE or AIM-CUE
- when the vm pilot number rings fast busy, what you should do is grab a "show log name messages.log tail" from the CUE CLI while this is happening (you can press ctrl-c to get to the exit out of that log display any time). It may scroll some (usuallly unimportant) debug-type stuff but you may see some EXCEPTION message or ERROR or something alarming like that which may indicate that there was some error accepting the call (such as all ports in use or whatever). Depending on what that information yields, there may be further troubleshooting required.
- for the choppy voice problem, are you sure it is recorded correctly? I.e. if you listen to the same message over and over does it always sound bad at the same place? Also, if you're leaving a message, if you press # there's an option to repeat the recorded message; if this is reproducible you might be able to verify for sure if it's recorded badly or not.
- You may want to open up a TAC case for this. What you'll want is to get a messages.log and atrace.log ('show logs' on the CUE) from the module with timestamps (as close as possible) of when the messages were left (assuming they were recorded poorly). On the AIM, the atrace.log is not recorded by default.
- In general, these problems most of the time aren't on the CUE side except when all traces are turned on or something like that so that the module is under excessive stress. If these calls that sound poorly are all originating from a remote gateway(s) or are begin played back to remote phones, I'd probably grab a PC and load ethereal on it and try to capture the audio stream to/from CUE to see if it isn't fine coming in/out of the module. TAC can help you with that process, as well.
