Telepresence Conductor and Telepesence Server failover

[gabriel.caclin]

Dear Community,

I am trying to figure out the use of a Telepresence Conductor compared to directly managed TPS (TelePresence Server) with the TMS.

I recently notice with 2 TPS behind one Conductor managed by a TMS, during a conference scheduled (in automatic connect), if the TPS running the conference goes down, TMS recreate the conference on the Conductor, which assign is to the last available TPS resource, but never reconnect the participants.

I was wondering that the Conductor is clever enough to tell the TMS to reconnect the participants, but no, it seems that it works by design...

Now, for a resiliency point of view, does removing the Conductor and directly manage the TPS by the TMS will solve this? From what I notice, if TMS is configured in automatic MCU failover, then without the Conductor, the scheduled conference on one TPS will be automatically recreated on the next available TPS and automatically reconnect the participants?

If someone can confirm this, that will be nice :).

Thanks !

[Patrick Sparkman]

What model TelePresence Server do you have?  It might not be possible to use the TelePresence Server without Conductor depending on it's model and you have it deployed in the environment.

TMS doesn't support automatic redial when a Conductor managed bridge goes down, the endpoints will either need to dial back in themselves or someone would need to connect them using TMS.  Below are some discussions that cover such scenarios and what was found, it's also covered in the Conductor with TMS Deployment Guide (XC3.0 with TMS 14.6) on pg 8 regarding MCU failover.

does-tp-conductor-support-mcu-redundancy

conductor-redundacy-failover-during-multipoint-conference

I'm not sure how the failover of a TMS managed bridge will function, as over the course of the past several years I never had n MCU/TelePresence Server fail on me.

[gabriel.caclin]

Well, the funny thing is: have one MCU directly managed by TMS, and one Conductor. If scheduling is made on MCU first, and this MCU goes down, TMS automatically reconnect all the participant and re-create the conference to the next bridges==> Conductor, within 30 seconds.

Now Cisco pushes the new design with Conductor and TPS, and it does less. Hard to understand the strategy, especially when SE/Sales told that this is made for it...

Failover is something very important, not because a TPS or MCU can goes down, but if there is a network/datacenter outage.