09-18-2013 11:20 AM - edited 03-18-2019 01:49 AM
Hi Telepresence Community.
I've been getting conflicting responses about Telepresence Conductor features specifically with dynamic failover during an active multipoint video conference. I have a single Conductor and two MSE8000 with HD blades with the MCU's located in different states. During a recent multipoint video conference scheduled with Conductor with 10 endpoints connected to the NY-MCU and 10 endpoints connected to the NJ-MCU. Fifteen minutes into the multipoint conference the NY MCU failed due to a power outage.
My question is can Conductor detect the lost MCU in NY and dynamically reroute the 10 video participants when they try to reconnect to the multipoint bridge? So the 10 participants on the NJ MCU remain on the bridge and the 10 participants in NY lose their connection and try to recconnect. Will Conductor route the 10 participants to a new resource or is Conductor only used to schedule and reserve the MCU resources and won't participate or provide a reroute to an available MCU such as our NY MCU outage?
I appreciate your input
Thank you
John
09-18-2013 11:33 AM
Hey John,
To answer your question, no Conductor does not have the ability to reconnect calls to another MCU if a call was setup on a conductor bridge and then that bridge goes down. It has the ability to select an active MCU to build the conference on when the conference is built up at the start of the meeting time, but once the conference goes active, if the MCU goes down, conductor will not move the conference to another MCU and have the calls reconnect on the fly. You would likely need to tear down that conference in TMS and generate a new one with the same endpoints using conductor and then conductor would rejoin those participants to the new working bridge that conductor selected.
I hope this answers your question!
09-18-2013 11:52 AM
Chad,
I do not believe that is entirely correct. Your statement would only apply to a Conductor/VCS/MCU Policy based deployment model. A Conductor/VCS/MCU B2BUA deployment model should allow for the Conductor/VCS to pick a new MCU and re-connect everyone automatically.
Thank you,
Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
http://www.kbz.com
e/v: justin.ferello@kbz.com
09-18-2013 12:11 PM
Hi Justin,
My deployment consists of a single Conductor. TMS, VCS and two MCU's located in two different states.
Does my deployment equal a B2BUA noted in your post? How can I get a firm answer to my question on dynamic rerouting after a group of video participants are knocked out of a MCU due to a hardware failure. If your information is correct is it noted in Cisco's documentation?
Thank you
John
09-18-2013 12:31 PM
Hey John,
I just got through testing this out in my lab with the B2BUA deployment, and the call failover did not work. I then spoke with a few other engineers and even the Conductor TME regarding this and they confirmed that Conductor does not have the ability to provide in-call failover like you are talking about at this time. Hopefully a future release may add that feature!
09-18-2013 12:48 PM
Chad,
That is interesting, I was sure that the Conductor PM told me the B2BUA deployment model offers this redundancy... What would be the point in using B2BUA otherwise?
Thank you,
Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
http://www.kbz.com
e/v: justin.ferello@kbz.com
09-18-2013 01:16 PM
Guess the biggest advantage is to streamline it with the CUCM deployment.
CUCM is the main focus, so why run around with dead weight which slows you down.
The VCS also has a b2bua, not only the lync gw but also the media encryption policy part.
Dont see a reason why a policy/api based system could not archive the same, maybe even
in a more advanced way as the conductor could control different vcs via the api.
Maybe even the failover handling and signaling could have benefits from the old style of api/policy way.
That said, in theory, yes, with a b2bua on a conductor you have control over the call,
and yes you could take action on it. but at least I did not see anything that this is possbile
by today.
Guess the biggest challenge is to properly identify that there is an issue where it can benefit
from being moved. From my perspective I would say its quite hard to filter out false positives and false
negatives. In addition its does not get easier if you have a component which tries to be more clever
than the user is, ...
Especally on geo redundancy it can be a challenge when you have a partial network outage
how to say what happens now, ...
(that could be a case for example where a api/policy based model could have an advantage).
To be honest, how often did you had issues that a MCU was plain dead in comparison to
network or human based errors.
So yea, it sounds like a cool feature, but think what other things might be more critical
Please remember to rate helpful responses and identify helpful or correct answers.
Please remember to rate helpful responses and identify
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide