How did you manage to make the channel securely bi-directional without transaction replacement? As the Wiki explains, the solution without transaction replacement is only secure in a single direction.
I rely on nLockTime and fees to switch directions. Basically, when you're going in one direction, the payee always has the incentive to broadcast the most recent refund transaction version and have it committed to the blockchain.
To switch directions, the nLockTime of the new refund version should be earlier. That way, the more recent version of the refund transaction is valid for inclusion in the blockchain first. I'd also increase the transaction fee in order to incent miners to include the newer version of a transaction over an earlier version for additional safety (in case the nLockTime difference between the versions is too small for the newest to be included by the time the second newest is valid).
I ended up presenting this concept Friday night in San Francisco. I think there will be a video put up; I'll link to it when it is.