These kinds of intermittent failures can be very tricky to track down. Ideally you'd get a sniffer trace from the Unity server right at the time the blank message is being generated. However, I know this is nearly impossible because typically any sniffer buffer is long overwritten by the time the message recipient reports the issue.
Try to find a commonality between these messages. For example, were these messages generated by external callers? Is there caller ID info that could indicate a particular route or gateway these calls came in on?
Having a report from one of the callers on what they experienced when the message was recorded would also be helpful. Did they actually leave a message or did they drop the call before recording? If they left a message did they end it by haning up or by pressing '#'?
One example I’ve seen of this symptom was a case where callers across a gateway would hang up before the recording. CCM would send a reorder tone packet to Unity but would not initiate teardown of the call until 30 seconds later. See CSCsb42730 for details. Once we knew what to look for it was fairly easy to reproduce. If you find your topology exhibits this behavior also, then there is a 8.0(1b)ES version of the TSP that you should get from TAC.
-Eric
