i can find no bugs related to this symptom as you've described it
is there any chance a user attempts to conference in a user during the call and MOH is played during that time by the Network or that the user is conferenced and puts the call on hold and MOH kicks in? you wouldn't happen to have duplicate ip addresses would you? (just thinking out loud here)
what type of mcast are you using? i recommend sparse mode or sparse-dense mode. (i use sparse-dense)
being multicast, one thing is true, the device must request a join to the Mcast group in order to receive the mcast stream.
this being the case, perhaps it would be best to attempt a sniffer capture to determine if in fact the device is requesting to join an mcast group. or at least you would be able to see the mcast stream arriving at the device and possibly see the source of reason why the stream was sent to a device that did not request it. you can also enable some mcast debugs to see what the router(s) in the path are doing with mcast.
(you can use the sniffer captures along with CCM traces to determine exactly what the devices are doing or being told to do by CCM)
(get your free sniffer software from http://ethereal.com)
also, being that you are using SR3A, although i find no bugs with this SR and had no similar symptoms myself when i was using this SR, perhaps you can upgrade to SR3C. (may be a last restort if all else fails)
last but not least, if you can contact TAC at http://cisco.com/tac or 800.553.2447, they may be able to help you go through your traces as a second set of eyes or if you're not able to understand the traces.
(i've always found it good to be able to have a second set of trained eyes looking for issues when these 'weird' symptoms appear that i just cannot resolve)
