The two CTIOS do talk to each other with a heartbeat but it's not the same as the way PGs talk to each other. With a PG, one side is active and one side is idle. With CTIOS, both are active and the client connects to both. It chooses one to be the primary source of events and if that dies, it uses the other. It does not necessarily switch back should the connection to the first be reestablished.
This is easily seen from the CTIOS Soft Phone. Fire it up and look at the one it's hooked up to. Stop that CTIOS and it will show that it's hooked up to the other. Start the first again - does it switch back?
So the answer is - nothing at all. Say you watch CTIOS A and stop CTIOS B. Now you will see a continual stream of messages from A as it tries to connect to its peer, but the connection can't be established.
Turn on display trace to screen and try this for yourself.
When both CTI Object Servers are running, do you see correct trace indicating that each peer is aware of each other and connected?
With CTIOSB stopped, start CTIOSA and watch the trace. It will repeatedly try to connect to its peer. When CTIOSB is started, this repeating trace should stop. If this is not the case and the config is correct, ensure that the binding order on the NICs has the public NIC above the private NIC.
With them both running, if you watch the trace of CTIOSB and stop CTIOSA, you should again see repeating trace as it tries to establish a connection to its peer. When you start CTIOSA, this heartbeat should stop and the trace will show connection to CTIOSA.
Is this working correctly?
When you say "CTIOSA loses the heartbeat to CTIOSB", how are you testing that? Are you saying if you stop CTIOSB, that the CTIOSA command window disappears and it restarts?
Are you sure it's the connectivity between CTIOS sides and not the connection from CTIOS to CTI Server? Check your CTI Server process logs and see if it is experiencing issues. The CTIOS processes will cycle themselves if they lose their connection to the active CTI Server.