cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
3692
Views
0
Helpful
22
Replies
Simon Battye
Explorer

Using Conductor with TMS 14.1

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,

1 ACCEPTED SOLUTION

Accepted Solutions
Kjetil Ree
Cisco Employee

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

View solution in original post

22 REPLIES 22
Justin Ferello
Contributor

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

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

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

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):

http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/admin_guide/Cisco_TMS_Admin_Guide_14-1.pdf

cheers,

Dale

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

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

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

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

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.?

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

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

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

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

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ
Content for Community-Ad

Spotlight Awards 2021