Telepresence Conductor Failover

[conie saga]

Hello,

We have one conductor & two TelePresence conference bridge.

We are in deployment phase & assuming that Telepresence are registered into conductor & conductor is connected to CUCM 10.5 through SIP Trunk.

In this scenario conductor is single point of failure. If conductor fails, CUCM won't be able to communicate with Telepresence.

What will happen if conductor fails ? Users won't be able to make conference calls ? To achieve failover can i configure 2 different SIP trunks in CUCM, one for CUCM to Conductor & second for CUCM to TP & assign priorities ?

We have one ISDN gateway CTI-3241-GWISDNK9 as well. What is the best place to deploy ISDN Gateway in network ? should it connected with Conductor or with CUCM ?

For scheduling conferences, what is the best place for Telepresence Management Suit also ? should it connect with Conductor or with CUCM ?

Regards,

Conie

[Patrick Sparkman · Accepted solution]

Hello Conie -

To answer your question:  What will happen if Conductor fails?

Because CUCM sees Conductor as the conferencing bridge, since the TelePresence Server is located behind Conductor, no conferences that use Conductor would be able to be start.  It would be the same as if you were using TelePresence Server directly with CUCM, and it were to fail, no conference that use the TP Server would be able to start.  The same would apply even if you used TMS.

[conie saga]

Hello Patrick,

Thanks for reply,

how should i configure CUCM so that if conductor fails it should directly contact to TP Server ?

As i mentioned in my post, Would it achieve by setting different priorities for conductor & TP Server under SIP Trunk ?

Regards,

[Patrick Sparkman]

I'm not able to answer the CUCM question as I've never worked with, nor have CUCM.  Perhaps someone else here in the forums can answer that.

[conie saga]

Thank you guys,

As per following Telepresence Datasheet, only MSE 8710 or TP 7010 support local & remote managed deployment mode, rest all supports only remotely managed mode having Conductor.

http://www.cisco.com/c/en/us/products/collateral/conferencing/telepresence-server/data_sheet_C78-7287571.html

" The Cisco TelePresence Server on Cisco MSE 8710 or Cisco TelePresence Server 7010 can be locally managed or remotely managed (by Cisco TelePresence Conductor). All other versions can be run only in remotely managed mode. "

Can any body confirm the above please ?

TP VMware won't work with CUCM via SIP Trunk ?

[Nick Halbert-Lillyman]

That's correct, but if you are only managing a single VMware TP server you can use the "free" version of Conductor.  You might be able to use two instances of the free conductor connected to CUCM?

[conie saga]

Thank for the confirmation.

As per following TP Server datasheet, VM version with 8-core VM can support maximum 2 concurrent calls (10180p + 720p). 

http://www.cisco.com/c/en/us/products/collateral/conferencing/telepresence-server/data_sheet_C78-7287571.html

How many participants can be in each call ?

Regards,

[Nick Halbert-Lillyman]

Each call is for one single-screen participant, but it depends what quality you're running.

If you are running 720p/30fps for instance, you should be able to get 8 x calls/participants out of 4 screen licenses.

If you run 1080p/30fps or 720p/60fps, this will go down to 4 calls out of 4 screen licenses.

You can also mix and match with conductor, so you could have 2 x 1080p/30fps calls and 4 x 720p/30fps calls at the same time.

Note that these all depend on the quality of the "content" stream, so increasing or decreasing the quality of this stream will affect how many resources you have.

[Nick Halbert-Lillyman · Accepted solution]

I'm pretty sure you can't do that - I'm assuming it works the same way as a VCS-based deployment where a TP server can be "locally managed" - i.e. has a SIP trunk directly to CUCM/VCS - or "remotely managed" where it's managed via Conductor.  I don't think you can do both.

If you are using a virtual machine, you could try gaining Conductor redundancy at the VM layer rather than having two Conductors (that's what we're doing and it seems to be working well so far).

I'm not sure if CUCM supports clustering of conductors, but that could be your other option.