If you have verified all WAN connections roundtrip times, packet drops, etc, I would concentrate your efforts on the remote sub that is failing to connect. If the database is beyond connecting back to the publisher to replicate, you may be better off just rebuilding the subscriber. Sometimes, if the Sub because outsynce to a point, there is no "fixing" it.

When you split the cluster across the WAN, you are playing with fire. It can be done, and it does work, but when things like this happen, it takes some time to fix. Typically should have a dedicated circuit only used for the CallManagers to replicate. Even if you are using a managed service such as MPLS, you can not guarantee that the provider is giving all the correct numbers. I have seen many dropped packets on ATT and other providers running "point to point" MPLSs across multiple routers, causing significant delays. The only way I could prove it was to have a third party come in and monitor the WAN for a couple days. The reports showed what we thought even though ATT said they showed no problems.

Im not sure on CUCM 4.x what the command is to force another replication. Most likely in SQL. In 5.x and 6.x you can use a dbReplication command at the shell. I would recommend having TAC look at the sub and see if there is way to force a new replication or update.

cheers