01-10-2013 07:12 AM - edited 03-18-2019 12:25 AM
Hi,
Now that TMS 14.1 has been released and the "Cisco TelePresence Conductor with Cisco TMS Deployment Guide" does not appear to be available as of yet; i'd be interested to hear what production/lab experiences people have had so far?
Does anyone know when the deployment guide will be released? Will i be able to cascade geographical conferences using TMS/Conductor?
Regards,
Solved! Go to Solution.
01-17-2013 08:04 AM
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
01-10-2013 07:22 AM
Simon,
I have been using the Conductor with TMS since BETA and it works great! Anyway, there is not that much to configure with TMS. You just add the Conductor to TMS and then program in an alias that TMS will use when scheduling conferences.
Then when you schedule a conference, if you require an MCU for the call it will automatically add the Conductor or you can add it manually to the call.
Thanks,
Justin
01-17-2013 04:24 AM
Hello Justin,
Is it so that you dont have to create any alias rules in the conductor, this will be fully managed by the TMS into the conductor?
So any ad-hoc conference you may have you need to create your self. But for TMS managed conference you only fill inn the alias in TMS?
Thanks
Rgs
Egil Hasting
01-17-2013 05:06 AM
Egil,
You must create an alias in the Conductor and then use the same alias in TMS for the scheduling to work. For example in Conductor I have tms.*@domain.com then in TMS under the Conductor properties I also enter tms.*@domain.com and now I can schedule conferences using TMS.
Thanks,
Justin
01-17-2013 05:17 AM
Hi Guys,
How to add, create aliases, etc the Conductor to Cisco TMS is covered in the new Cisco TMS Admin document (starting on page 66):
cheers,
Dale
01-17-2013 05:19 AM
Dale,
Was checking out that section and saw this:
Only Cisco TelePresence Conductor version XC1.2 is currently supported by Cisco TMS
Is this still true? We are running XC2 on ours, it works fine but would hate to not get support if something went wrong.
Thanks,
Justin
01-17-2013 05:34 AM
Justin,
Yes, this is true from a Cisco TMS 'testing POV'. However, the API is backwards compatible so everything 'should work' but from an 'official POV', if something goes amiss from a 'TMS POV', then this is why we state what we state in the release note
cheers,
Dale
01-17-2013 05:37 AM
Justin,
If you only use the same features in your XC2.0 Conductor as you did in your XC1.2 Conductor, you should be safe.
What we mean by 'only Cisco TelePresence Conductor version XC1.2 is currently supported' is that nothing XC2.0-specific (Unified CM support, TelePresence Server 3.0 'flex mode' etc) is guaranteed to work. Some of it will probably work, but we make no guarantees at this time.
Regards,
Kjetil
01-17-2013 05:40 AM
Guys,
Ok thanks, can you make sure that Jefferson or Nico involve us in the next TMS EFT so we can test these features then. We are very interested in the TPS portion of Conductor/TMS as we have (2) of them just sitting around
Thanks,
Justin
01-17-2013 06:04 AM
Dale,
I have been reviewing the information you provided and I am a bit confused now.
1) There is a section about "verifying" the MCU in TMS is managed by Conductor. All the guide states is that you should reference the MCU in Conductor & TMS the same way, either by IP or DNS. My question is how does this "verify" that TMS knows the MCU is managed by Conductor? Also what would happen if TMS did not know the MCU was managed by Conductor?
2) I have scheduling working a lot differently than the guide suggests in my own environment. All I did was create an alias template on conductor of tms.*@domain.com then in TMS i put the same alias under the Conductor properties and this works fine so far. So why do I need to create a whole new conference template, then setup the call policy prefix in Conductor, then create a whole new call policy rule in the VCS?
3) What would happen if TMS does not have "exclusive" access to the conference template on Conductor?
I am available for a video call or phone call if you or someone else would rather reach out to me that way to answer all these questions I have.
Thank you,
Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
e/v: justin.ferello@kbz.com
01-17-2013 06:07 AM
I would also like to add that in the template we are using on the Conductor we have a option called "Scheduled Conference:" set to "Yes". I tought this was the option ensuring that TMS got "ownership" of the template, and then the alias.?
01-17-2013 06:23 AM
Egil,
I agree with you on that, I have played with that setting that seems to lock out everything except TMS, so I am not sure why all the other steps with the Call Policy & such are required.
Thank you,
Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
e/v: justin.ferello@kbz.com
01-17-2013 07:31 AM
I would also like to add that in the template we are using on the Conductor we have a option called "Scheduled Conference:" set to "Yes". I tought this was the option ensuring that TMS got "ownership" of the template, and then the alias.?
Hi,
This setting does not exist in Conductor XC1.2, which is what TMS officially supports. See also my reply to Justin.
Hilsen Kjetil
01-17-2013 07:28 AM
1) There is a section about "verifying" the MCU in TMS is managed by Conductor. All the guide states is that you should reference the MCU in Conductor & TMS the same way, either by IP or DNS. My question is how does this "verify" that TMS knows the MCU is managed by Conductor? Also what would happen if TMS did not know the MCU was managed by Conductor?
You aren’t verifying that the MCU is managed by a Conductor, you are verifying that either:
a) The Conductor knows the MCUs by their IP addresses and that TMS knows the MCUs by their IP addresses, or
b) The Conductor knows the MCUs by their FQDNs and that TMS knows the MCUs by their FQDNs
If you mix FQDNs and IP addresses, TMS’s Conference Control Center won’t be able to resolve calls correctly.
2) I have scheduling working a lot differently than the guide suggests in my own environment. All I did was create an alias template on conductor of tms.*@domain.com then in TMS i put the same alias under the Conductor properties and this works fine so far. So why do I need to create a whole new conference template, then setup the call policy prefix in Conductor, then create a whole new call policy rule in the VCS?
That is because in Conductor XC 1.2, you get into problems if dial in participants call in early to scheduled conferences. If they do, the dial-ins will create a new adhoc conference on the Conductor. When TMS two minutes later tries to create the same Conference, it will fail, and then try to a failover and create the conferences on another bridge.
We thus recommend creating a new Conductor Conference template and controlling access to it using a Call Policy to avoid this unfortunate situation.
3) What would happen if TMS does not have "exclusive" access to the conference template on Conductor?
See my answer to 2).
Regards,
Kjetil
01-17-2013 07:39 AM
Kjetil,
Thank for all the answers. Since XC2 is not supported in TMS14.1 I guess you cannot comment on the 'Scheduled Conference" setting and how it relates to TMS?
Thank you,
Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
e/v: justin.ferello@kbz.com
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