Conductor with TMS Questions

Rainer S · ‎07-02-2014

Hi all,

I have two questions about Conductor used with TMS.
But first the Setup:
- TMS 14.3.2
- Two Conductor (clustered) XC2.3, integrated to VCS with call policy service; both conductor are in the TMS
- TPS Sv: 4.0(1.57) remotly managed via Conductor, but still added in TMS

1st Question:
For scheduled confereneces the TMS can set a Number in the Call Settings (Max Number of Concurrent Scheduled Calls: 10)
This number can be set in the TMS differntly for each Conductor

The maximuim number of conferences for the whole cluster should be seperated between those conductors? Is that correct?

2nd Question:
How does the goelocation routing work with the Conductor?

There are TPS (in two different areas) managed behind a Conductor (located in area 1)
Conferences with more endpoints from area 2 should use the the tps from areas 2. In short words the conductor should choose "the nearest" TPS!

How can i set that up? I didn't find anything to manage in the Conductor settings!
Is this only possible with the b2bua integration possible?

Kind regards,
Rainer

Patrick Sparkman · ‎07-02-2014

First of all, clustered Conductors are not supported with TMS at this moment. Only one of them should be added into TMS, if a failover is needed or the first peer goes down, the second peer would need to be added yourself. There is already an enhancement request out there for it, CSCud83776.

Until TMS supports Conductor clusters, TMS sees each Conductor's call settings as separate, not the same.

I've never used geolocation, so I don't have an answer on that.

In regards to using Conductor call policy, that will be phased out soon, and it's suggested you should migrate to using Conductor with the B2BUA.

Rainer S · ‎07-03-2014

I still need the monitoring, so I removed the booking functionality on one part of the cluster. That should work.

I'm planning to migrate to the other vcs deplyment (b2bua), but there where some external restrictions why i couldn't do it in the first place.

I need for ad-hoc meetings an IP address. Do i need two ip addresses if i use differnt pools? Same question for rendezvous.

But for scheduled meetings I'm not quite sure what will come..

Any expierience shared from whom that already uses a conductor with geolocation with tps in differnt areas is appreciated!

Patrick Sparkman · ‎07-03-2014

[...]I removed the booking functionality on one part of the cluster. That should work[...]

Unless you remove and purge that 2nd Conductor, you won't have a way to transfer all the scheduled conferences from a failed Conductor to it's peer so they can take place.

Conductor just needs two IPs I believe, a management IP, and an IP used for connecting to your VCS for calls. Our Conductors are setup with conference type "Rendezvous". As far as pools are concerned, you can only have one MCU added to one pool at a time, Conductor will throw an alarm if an MCU is added to more than one pool. We have two MCUs and currently one is for scheduled calls and the other for ad hoc, each has there own pool and 1 MCU added to each.