There was a misunderstanding somewhere along the way. You can have a CCM cluster and use TAPI ports simultaneously.

Depending on the TAPI application however, the TAPI client will not necessarily fail over from one CallManager to another. Some apps do support this, such as Cisco WebAttendant.

If you are using a home-grown TAPI application, and it as well as the phones are all using CallManager A as the primary, B as secondary, and A fails, then the phones will re-home to B but the TAPI client may not.

Note that this is how it would currently function. Again, TAPI clients can be written to fail over.

Please note...regardless of how many CallManagers are configured, they are ALWAYS associated with a cluster. So you can have a single MCS cluster or a six MCS cluster of CallManagers. With this background, yes, its possible to configure TAPI or JTAPI ports on any CallManager in a cluster.

What is not possible is redundancy of TAPI-based applications across a CallManager cluster. If the CallManager to which a TAPI or JTAPI app is "pointed" to fails, there is no provision for the application to receive call processing services from an alternate CallManager. Call processing redundancy for TAPI and JTAPI apps will be made available in CallManager 3.1.

Further, there are feature transparency constraints. If a SoftPhone (TAPI) is operating in first-party call control mode, where it can control an associated IP phone, the TAPI port has to be registered to the same CallManager in the cluster as the IP phone is associated with. If the CallManager fails, the SoftPhone will fail but the IP phone will fail over to its secondary CallManager. This will be confusing to the user, in that, they will attempt to use the SoftPhone to initiate a call, see that the SoftPhone is not working, but that the associated IP phone is working. Once they are past the confusion, they can simply dial directly from the IP phone. All services are available to the IP phone, even when the controlling SoftPhone is out of service.