Cisco Cisco TelePresence Video Communication Server Expressway Maintenance Manual
Conference Factory template (Applications > Conference Factory)
The template used by the Conference Factory application to route calls to the MCU is peer-specific, as it must be
unique for each peer in the cluster.
unique for each peer in the cluster.
VCS front panel display mode (configurable through CLI only)
The
xConfiguration Administration LCDPanel Mode
CLI setting is specific to each peer.
Sharing Registrations Across Peers
When a cluster peer receives a search request (such as an LRQ, ARQ or an INVITE), it checks its own and its peers'
registration lists before responding. This allows all endpoints in the cluster to be treated as if they were registered
with a single VCS.
registration lists before responding. This allows all endpoints in the cluster to be treated as if they were registered
with a single VCS.
Peers are periodically queried to ensure they are still functioning. To prevent delays during call setup, any
nonfunctioning peers do not receive LRQs.
nonfunctioning peers do not receive LRQs.
H.323 registrations
All the peers in a cluster share responsibility for their H.323 endpoint community. When an H.323 endpoint registers
with one peer, it receives a registration response which contains a list of alternate gatekeepers, populated with a
randomly ordered list of the IP addresses of all the other peers in that cluster.
with one peer, it receives a registration response which contains a list of alternate gatekeepers, populated with a
randomly ordered list of the IP addresses of all the other peers in that cluster.
If the endpoint loses contact with the initial peer, it will seek to register with one of the other peers. The random
ordering of the list of alternate peers ensures that endpoints that can only store a single alternate peer will failover
evenly across the cluster.
ordering of the list of alternate peers ensures that endpoints that can only store a single alternate peer will failover
evenly across the cluster.
When using a cluster, you may want to reduce the registration Time to live on all peers in the cluster from the default
30 minutes. This setting determines how often endpoints are required to re-register with their VCS, and reducing it
means that if a cluster peer is unavailable, the endpoint will failover more quickly to an available peer.
30 minutes. This setting determines how often endpoints are required to re-register with their VCS, and reducing it
means that if a cluster peer is unavailable, the endpoint will failover more quickly to an available peer.
Note:
By reducing the registration time to live too much, you risk flooding the VCS with registration requests, which
will severely impact performance. This impact is proportional to the number of endpoints, so you should balance the
need for occasional quick failover against the need for continuous good performance.
need for occasional quick failover against the need for continuous good performance.
To change this setting, go to Configuration > Protocols > H.323 > Gatekeeper > Time to live.
SIP registrations
The VCS supports multiple client-initiated connections (also referred to as "SIP Outbound") as outlined in
This allows SIP endpoints that support RFC 5626 to be simultaneously registered to multiple VCS cluster peers. This
provides extra resiliency: if the endpoint loses its connection to one cluster peer it will still be able to receive calls via
one of its other registration connections.
provides extra resiliency: if the endpoint loses its connection to one cluster peer it will still be able to receive calls via
one of its other registration connections.
You can also use DNS round-robin techniques to implement a registration failover strategy. Some SIP UAs, such as
Jabber Video, can be configured with a SIP server address that is an FQDN. If the FQDN resolves to a round-robin
DNS record populated with the IP addresses of all the peers in the cluster, then this could allow the endpoint to re-
register with another peer if its connection to the original peer is lost.
Jabber Video, can be configured with a SIP server address that is an FQDN. If the FQDN resolves to a round-robin
DNS record populated with the IP addresses of all the peers in the cluster, then this could allow the endpoint to re-
register with another peer if its connection to the original peer is lost.
Sharing Bandwidth Across Peers
When clustering has been configured, all peers share the bandwidth available to the cluster.
■
Peers must be configured identically for all aspects of bandwidth control including subzones, links and pipes.
■
Peers share their bandwidth usage information with all other peers in the cluster, so when one peer is
consuming part or all of the bandwidth available within or from a particular subzone, or on a particular pipe,
this bandwidth will not be available for other peers.
consuming part or all of the bandwidth available within or from a particular subzone, or on a particular pipe,
this bandwidth will not be available for other peers.
186
Cisco TelePresence Video Communication Server Administrator Guide
Clustering and Peers