Does anyone know when the deployment guide will be released?
As Dale says, the info is already there in the TMS 14.1 admin guide.
We’ll rearrange the information and republish it as a new document Cisco TelePresence Conductor XC1.2 with Cisco TMS 14.1 Deployment Guide (or something like that) in the not too distant future, hopefully next month.
Will i be able to cascade geographical conferences using TMS/Conductor?
TMS has no control over which bridges the Conductor chooses to connect participants to, so if I understand you correctly: No.
i'd be interested to hear what production/lab experiences people have had so far?
I might be slightly biased here, but I really love Conductor scheduling. It can be a bit of a hassle to set up correctly (as it is a complex piece of infrastructure equipment that also requires changes to your dial plan and MCUs), but as soon as you are up and running, it makes life so much easier.
The major advantage IMHO is that the Conductor takes distribution (MCU cascading) away from TMS’s control. TMS has to keep a lot of legacy products in mind when deciding how to route call legs between different bridges, and the Conductor – which has no such constraints – can optimize for a modern TelePresence deployment. End users both get a simpler solution (i.e. one number to dial), and a superior TelePresence experience (i.e. a more seamless immersive experience when connected to a huge conference that spans multiple bridges).
The Conductor also simplifies maintenance, as it looks like one gigantic bridge from TMS’s perspective. If you are retiring or temporarily removing an MCU from your deployment, you don’t have to go into future conferences in TMS, re-route the calls, save them again, and then notify end users that the bridge number changed. With the Conductor, it all happens completely transparently to TMS, which does not need to know or care about which physical bridge that hosts the conference.
Another thing I like: Users often schedule way more MCU capacity than they actually need, “just in case”. With the Conductor, we allow deliberate overbooking of MCU ports, so that organizations better may utilize their MCU ports. This wouldn’t be appropriate in some organizations, where guaranteed ports are required, but it can be a very efficient way of maximizing MCU usage.
Regards,
Kjetil
