I just got done fixing this on a clients router, it was an IOS bug and a IOS upgrade fixed it. They were running into bug CSCdu53333 which was fixed in 12.2(6a). According to the bug navigator, this was fixed in 12.2(6.7)T for the T train. You might be running into another issue however. My client was on 12.2(5) and we went to 12.2(12) but thats a different train. See the URL the other person posted for more details.
You can get around this issue by reloading the router, which brings the timed out DSPs back to life. the (1, 14, 2) middle # 14 is the Dsp Id. DSP 14 is one of the DSPs on the PVDM module in socket 0 on the NM-HDV. These were first ones to timeout for my client as well. It took on average of 14-20 hrs before they timed out.
You can do a test dsp (slot# of NM-HDV) and choose option 1 to query each DSP. They will come back as being ALIVE or NOT RESPONDING or might not respond at all. In my case the timed out ones didn't even respond.
If you have open voice-ports or channels, you can move the call to another voice-port which may provide a workaround. Each voice-port is bound to a different DSP. You can get the voice-port to DSP id mapping by choosing option 2 in the test dsp command above.
The VTSP-3-DSP_TIMEOUT will appear in logs or across console a few seconds after a call is made to one of the voice-ports tied to a DSP that is timed out. So, if you know that dial-peer # you can do 'csim start ###' at console/telnet and it should fail if DSP is sleeping and a few seconds later you'll see the error scroll by if you have term mon on or are on console.
HTH, Erick
