Is it possible to use both CUCM and TMS with TelePresence Conductor?
The TMS deployment guide for Conductor only mentions VCS for call control...
The TMS with Conductor deployment guide is essentially only for TMS 14.1 and Conductor 1.2 with the VCS in Policy Mode type deployment; we are currently waiting for an official update on this guide.
This is from the TMS 14.4 release notes regarding general TMS / Conductor use:
TelePresence Conductor scheduling limitations
As the TelePresence Conductor scheduling solution has notable limitations at this time, we recommend carefully considering these Limitations [p.66] and their workarounds prior to deployment. Upcoming releases of TelePresence Conductor and Cisco TMS will address these limitations, and an updated deployment guide for Cisco TMS with TelePresence Conductor will be made available at that time.
One hurdle in TMS 14.4 has already been made but this still doesn't include Conductor support for B2BUA deployments off of CUCM using a SIP trunk:
From the TMS 14.4 release notes:
Scheduling for Cisco TelePresence Server and Cisco TelePresence MCU SIP-trunked to Unified CM
It is now possible to schedule conferences hosted on TelePresence Servers and TelePresence MCUs that are SIP-trunked to Unified CM and in Locally Managed operation mode.
So right now it is not currently supported but I would advise reaching out to your Cisco Account Team to discuss the time frame for upcoming support here in the future.
now i've a CUCM 10.5 with telepresence conductor, virtual telepresence, expressway-c,expressway-e and TMS 14.4
the telepresence conductor is integrate with cucm to work on adhoc conference and redezvous. what is the best practice to implementing TMS 14.4 on this architecture? the documentation is very confuse.
Your deployment should work fine with TMS 14.4 (apart from the caveats mentioned in the TMS release notes).
I would recommend setting up a bridge pool for scheduled use only, with a separate service preference. Have it configured as you do it for rendezvous, and make only that service preference bookable in TMS.
can you explain how you configured. i'm only one conductor and one telepresence server.
i can share same conference brigde with ad-hoc, redenvouz and tms?
You cannot shared ad-hoc,rendezvous and scheduled with one conductor/telepresence server. You will only be able to do ad-hoc and rendezvous. You will need a dedicated a bridge for scheduled
to use small scheduler on TMSPE need any adicional lincense?,
the solution only include jabber using expressway c/e and one SX80, the cucm is 10.5, think what is the best practice to use the telepresence server with conductor.
if use the telepresence server with tms or only leave the telepresence server/condutor to ad-hoc / redenvouz conference.
I have a deployment of VCS control and Expressway and Telepresence conductor and Telepresence server. I configured the following for the Sip domain and registered all the VC equipment's from through our VCS control.
I configured all the appliances for Internal calls initialed and the for the external call i just need some of the DNS and SRV records for an external calls.
I just have a some quires according to this deployments.
Can I move conferences from one conference to the other with out disconnecting the calls?
No, the endpoint must disconnect from the conference it's currently connected to, and reconnect into the other conference.
I see your other post asking this question and more: vcs-exp-vcs-contrl-telepresence-conductor-and-telepresence-server-deployment, I'll reply there so not to dig up an old thread any more than needed.
Could you explain on this, is it mandatory for TMS to use a dedicated MCU for scheduling or only a recommendation due to scheduling/best effort limitations?
For example, could i use one mass resource of ports for all three scheduling methods if i knew the backend clustered MCU's could support the port capacity?
Yes its possible.
The reason why you dont see TMS is because scheduled conferences with conductor are best effort and Cisco is recommending against this architecture until this limitation is fixed.