4.1(1)ES8 was a TSP ES build. Those never get published as Unity ESes. Instead, the TSP setup from that build is repackaged into a general TSP ES. That one in particular ended up as 8.1(1)ES1.
The fix you are looking for was also then rolled into the next TSP release, 8.1(2), and of course the more recent 8.1(3) release. Both of these are available for download on cisco.com. I'm not sure why CSCsc26421 didn't show up in the 8.1(2) release notes but I am certian that the fix is in there.
The bug there was that under certian conditions ports would lock and stop answering calls. Hence the first line of the bug release note: "Unity stops accepting calls on affected ports". The fix was to harden the TSP such that it could better handle these conditions, properly clear the port, and immediately be ready to accept the next incoming call.
If you're seeing the event log errors then you are hitting such a condition. If your ports don't get locked up when this happens then the bug fix is working.
In particular, Unity has attempted to answer an incoming call by sending SteationOffHook to CCM. But it seems CCM never fully responds to the offhook request. This is considered an error condition. I don't think there's much else Unity can do with this other than note that the condition has occurred (in the event log), clear the port, and move on with the next call.
Ok. Is there any way to get rid of the event log errors or reduce them to warning/informational? Trying to filter out errors for the event log monitoring we do and have seen other errors with same error type for different issues so don't want to filter out on that.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...