TMS reserves current CTC's (Conductor's) resources for future conferences

Question

Hi All,
Can anybody confirm the way CTC works with TMS concerning resource reservation and control? Also there are some questions long to be answered...
From my experience, after creating a conference TMS is communicating it to CTC.  CTC checks for resources (log messages: "device.query"; "participant.enumerate") and reserves them (for a period of whole time: since creation time till the conference ends). That reservation period comes from problems we have with scheduling next conferences (not from any system logs or statistics).
Is it possible to check the reserved resources on CTC? How to allow CTC to oversubscribe? How to make TMS-CTC reserve resources ONLY for the period of the scheduled conference time and not for the period from creation time till the end of the conference?
I read in documentation, that if MCU is dedicated only for scheduled conferences, then resources are reserved ONLY for a scheduled conference time (not from the time it was created). Can anybody confirm?
How to split MCUs for a group of 3 MCUs for scheduled conferences and one for Ad-hoc?
Thanks inn advance for answers and hints!

Answer 1

Something came to me this morning, and I just tested it, the reason you're seeing 65 for the max participants is because of a miss configuration of your conference template.  You need to change the number of cascades to 3.
With it set to use 2 cascades, you can only cascade up to 3 conference bridges, across those conference bridges you'd have 72 total video ports (30+30+12).  Subtract 4 video ports for the cascade links created between conference bridges, as a single cascade will take 1 video port from each MCU.  Subtract 3 video ports for the cost of using content, 1 from each MCU, reference the API guide I linked to earlier for more details.  In the end, you're left with the 65 max participants that Conductor is reporting to TMS that can be scheduled using that conference alias.
After you change the number of cascades to 3, Conductor should report to TMS that the max participants should be 92.  If you need help understanding the math, let me know, just remember: total video ports in conference bridge pool - video ports used for each cascade - cost of MCU content = max participants.