Sharing Registrations Across Peers; Sharing Bandwidth Across Peers - Cisco TelePresence Administrator's Manual

Video communication server
Hide thumbs Also See for TelePresence:
Table of Contents

Advertisement

Note: configuration data that is applied across all peers should not be modified on non-master peers. At best
it will result in the changes being overwritten from the master; at worst it will cause cluster replication to fail.

Sharing registrations across peers

When one VCS in a cluster 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.
Peers are periodically queried to ensure they are still functioning. To prevent delays during call setup, any
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.
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.
Note: when using a cluster, you should change the registration Time to live on all peers in the cluster from
the default 30 minutes to just a few minutes. This setting determines how often endpoints are required to re-
register with their VCS, and reducing this to just a few minutes ensures that if one VCS becomes
unavailable, the endpoint will quickly failover to one of its peers. To change this setting, go to
configuration > Protocols > H.323 > Gatekeeper > Time to
SIP registrations
The VCS supports multiple client-initiated connections (also referred to as "SIP Outbound") as outlined in
RFC
5626.
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.
You can also use DNS round-robin techniques to implement a registration failover strategy. Some SIP UAs,
such as Movi™ v2.0 (or later) clients, 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
n
pipes.
Cisco VCS Administrator Guide (X7.1)
Clustering and peers
live.
VCS
Page 142 of 479

Advertisement

Table of Contents
loading

This manual is also suitable for:

Telepresence x7.1

Table of Contents