Can you paste the error message here? What version of IOS and feature set are you on currently with these errors? DSP timeouts were a bug that was fixed in 12.2(6a). 12.2.13 is latest 12.2 mainline release at moment.
Can you post a sanitized configuration if possible? I've fixed 2-3 problems involving 3600s and NM-HDVs for clients of ours so can help point you in the right direction perhaps. One was code and the other was a couple bad PVDMs (DSP modules).
For me, troubleshooting NM-HDVs I usually use the following commands when placing test calls:
show voice call summary (shows call status). on Inbound calls into NM-HDV the status won't change if the call isn't making it past the DSP
On calls from other sites going out the NM-HDV you'll see a connect message but user on phone probably will get dead silence.
Other useful commands,
test dsp (slot # of controller) then option 1
this will query all the DSPs and they will report ALIVE if they are still up (have term mon if telneted in).
test dsp (slot #) then option 2 (similar to show voice dsp but more detailed) gives you detailed voice-port to dsp id mappings. This way you can pinpoint calls on voice-ports that aren't working to certain DSP id's. Theres a NM-HDV doc on cisco.com with PVDM DSP ID # breakdown per SIMM socket. I have the link at the office.
If you do narrow it down to a flaky DSP you can change the ds0-group # to try to get a new voice-port with a different DSP id. You don't need to change the timeslot #. This will require reconfiguration of dial-peers and voice-ports however. If the ds0-group # isn't a big change you may end up on same set of DSPs. I haven't figured out exactly how voice-ports map to DSP id's yet and have been trying to gather information on this from TAC. It appears to use the first available , but the higher the ds0-group # the higher the dsp id.
HTH, Erick
