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 6 of 10
Connecting multiple MCUs to a cluster of Cisco
VCS peers
VCS peers
Requirements
When connecting multiple MCUs to a cluster of Cisco VCS peers, it is important that:
failure of any Cisco VCS will not stop new conferences being set up
conference calls that are not on MCUs directly connected to a Cisco VCS that goes out of action
should continue unimpeded
should continue unimpeded
all MCUs connected to the cluster are used to host conferences
calls made by different people for the same conference ID must be directed to the same MCU
if there is an imbalance of callers on one or more MCUs and it or they approach their capacity
(reporting “out of resources”), new conferences should be created on a less busy MCU
(reporting “out of resources”), new conferences should be created on a less busy MCU
Operation
Each MCU is configured to register the same conference service prefix(es) onto the Cisco VCS to
which it registers. When a call for a conference arrives at a Cisco VCS, that Cisco VCS will check to
see whether that conference ID is already registered anywhere on the cluster of Cisco VCS peers to
which it belongs.
which it registers. When a call for a conference arrives at a Cisco VCS, that Cisco VCS will check to
see whether that conference ID is already registered anywhere on the cluster of Cisco VCS peers to
which it belongs.
If the conference ID is registered (i.e. the conference has already been initiated), the call will be
routed to the MCU that registered the conference ID.
routed to the MCU that registered the conference ID.
If the conference ID is not registered by any of the MCUs across the cluster, but the required
conference service prefix is registered by one or more MCUs, then the Cisco VCS receiving the
call will check to see whether another call has been made for this conference ID recently
conference service prefix is registered by one or more MCUs, then the Cisco VCS receiving the
call will check to see whether another call has been made for this conference ID recently
•
If there has been no other recent call to this conference ID (i.e. this is the first), the Cisco
VCS will randomly choose, from across the cluster, one of the MCUs that has registered a
matching service prefix, and will use that MCU for this conference ID. The Cisco VCS will
route the call to that MCU so that the conference may be set up.
VCS will randomly choose, from across the cluster, one of the MCUs that has registered a
matching service prefix, and will use that MCU for this conference ID. The Cisco VCS will
route the call to that MCU so that the conference may be set up.
.
2 This is X4 functionality – prior to X4, calls may traverse up to 2 clustered VCS peers. If a call traverses 2 VCS peers, then
failure of either peer will cause that call to drop.
failure of either peer will cause that call to drop.
3 Recent = within 1 minute. 1 minute gives the MCU plenty of time to register the full conference ID of the ad hoc conference
that it has been requested to create.
that it has been requested to create.