Cisco Cisco TelePresence Video Communication Server Expressway
Connecting multiple MCUs to a cluster of Cisco VCS peers
Cisco VCS Deployment Guide: Connecting MCUs to Cisco VCSs for resilience and capacity
Page 7 of 10
•
If there has been a recent call to this conference ID, the Cisco VCS will route this call to the
same MCU to which the other call to this conference ID was routed, regardless of whether
the MCU is registered to that particular Cisco VCS or another Cisco VCS in the cluster. (This
handles the situation where one or more callers dial in at almost the same time as the
initiator, and so require their call(s) to be routed to the correct MCU before the MCU has had
time to register the new conference ID.)
same MCU to which the other call to this conference ID was routed, regardless of whether
the MCU is registered to that particular Cisco VCS or another Cisco VCS in the cluster. (This
handles the situation where one or more callers dial in at almost the same time as the
initiator, and so require their call(s) to be routed to the correct MCU before the MCU has had
time to register the new conference ID.)
Note: If any MCU is nearly full of callers (or has reached the limit of the number of conferences it can
handle) it reports “out of resources” to the Cisco VCS to which it is registered. Any Cisco VCS peer
wanting to set up a new conference will take this into account and will adjust the randomization
algorithm to omit the nearly full MCU(s). The “out of resource” report will not affect the routing of
callers to existing conferences. In this way, callers to conferences that have already been set up will
continue to be sent to the appropriate MCU so that they can be in the same conference as all others
dialing that conference ID; new conferences will only be set up on MCUs that are not reporting “out of
resources”.
handle) it reports “out of resources” to the Cisco VCS to which it is registered. Any Cisco VCS peer
wanting to set up a new conference will take this into account and will adjust the randomization
algorithm to omit the nearly full MCU(s). The “out of resource” report will not affect the routing of
callers to existing conferences. In this way, callers to conferences that have already been set up will
continue to be sent to the appropriate MCU so that they can be in the same conference as all others
dialing that conference ID; new conferences will only be set up on MCUs that are not reporting “out of
resources”.
For capacity and resilience, register to Cisco VCS cluster peers as many MCUs with the same service
prefix(es) as are required. The MCU selection functionality works across a cluster of Cisco VCS peers
just as well as it does in a single Cisco VCS.
prefix(es) as are required. The MCU selection functionality works across a cluster of Cisco VCS peers
just as well as it does in a single Cisco VCS.
Configuration
1. MCUs should be configured such that approximately the same number of MCUs are registered to
each Cisco VCS peer.
2. Configure each MCU to register identical service prefix(es) to their Cisco VCS peer.
3. Configure each MCU to register with a Gatekeeper registration type =MCU (standard),
3. Configure each MCU to register with a Gatekeeper registration type =MCU (standard),
configurable on the Settings > Gatekeeper page.
The Cisco VCS cluster then handles all the conference call routing.
Note: The Gatekeeper registration type MUST NOT be Gateway because otherwise the Cisco
VCS will distribute calls to a specific conference ID randomly across all MCUs that have registered a
matching prefix. Only if Gatekeeper registration type is MCU will the Cisco VCS ensure that calls to
the same conference ID get routed to the same MCU.
VCS will distribute calls to a specific conference ID randomly across all MCUs that have registered a
matching prefix. Only if Gatekeeper registration type is MCU will the Cisco VCS ensure that calls to
the same conference ID get routed to the same MCU.