Using Conductor with TMS 14.1

[Simon Battye]

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,

[Justin Ferello]

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

[egilhasting]

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

[Justin Ferello]

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

[daleritc]

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

[Justin Ferello]

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

[daleritc]

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

[Kjetil Ree]

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

[Justin Ferello]

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

[Justin Ferello]

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

[egilhasting]

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

[Justin Ferello]

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

[Kjetil Ree]

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

[Kjetil Ree]

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

[Justin Ferello]

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