If you've already changed the hardware in the CPCI cabinet, then it sounds like you've changed the DSCXL's anyway, and so you've had new RAM already.
The software version you have listed is for the Assistant. What is the RMX build?
From V4 you needed 1GB DSCXL, and that meant you either increased the RAM in the older card with an extra module, and not all cards could support the extra module, or you used the newer cards with 1GB RAM installed. Are both your DSCXL cards the same hardware variant?
I suppose you are 100% sure you have not crossed an A/B cable from RTM to the LTU? The shelf can come in service when you do that, but you can get bizarre faults.
The problem with working on this is it's a big OS4K, and the testing is not without downtime. I suppose it's 24/7. But with downtime allowed, you could swap the two DSCXL's, is the problem now on CCA or CCB? If you turn off all the LTUs and unplug from RTM, do you still have the problem? Reconnect one by one, when does the problem come? There's things to try but you need downtime. APE's would help you with the IPDA downtime, if they're offline that's a different reason to CCB.
What's in the HISTA when it restarts? RTM can cause strange things too, might be worth downloading the RTM logs (act-ussu:dllogfl
In the newer 4Ks, unreachable IPDA can cause a processor switchover. If CCA talks to IPDA but CCB can't, and you switch to CCB, it will switch straight back. I think on the older DSCXLs it needed a physical layer 1 issue on the CC IPDA port to switch, not like V6 and above where it will switch on layer 3 problems.
Changing the cabinet might be useful, but it's a complete coin toss. I would spend more time trying to locate at what point the error comes. From your description it's easily reproducible.
Is anything plugged into the ATLAN? You've not got a call logger sitting on there with a 192.0.2.2 address?
Difficult to say without the HISTA. And probably difficult to say with it, by the sound of it.