Filter
Top Products
96
D14049.04
JULY 2008
Grey Headline (continued)
TANDBERG VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction Getting Started
Overview and
Status
System
Conguration
VCS
Conguration
Zones and
Neighbors
Call
Processing
Bandwidth
Control
Firewall
Traversal
Appendices
Applications Maintenance
Clustering, Peers and Alternates
A VCS can be part of a Cluster of up to six VCSs. Each VCS in the Cluster is a Peer of every other
VCS in the Cluster.
The purpose of a Cluster is twofold:
to increase the capacity of your VCS deployment compared with a single VCS
•
to provide redundancy in the rare case that a VCS becomes unavailable (for example, due to a
•
network or power outage).
All Peers in a Cluster must use TMS to ensure they are congured identically for subzones, zones,
links, pipes, authentication, bandwidth control and call policy. They must also have identical sets
of options keys installed. Peers share information with each other about their use of bandwidth,
registrations, and FindMe users. This allows the Cluster to act, as one large VCS Local Zone.
The diagram opposite shows four Peers clustered together to form one large Local Zone.
”Alternate” is an H.323 term for a system used to provide redundancy to a Primary
gatekeeper, and prior to version X3.0 the VCS supported Alternates. From X3.0 onwards,
redundancy (along with other features) is provided by clusters of Peers, which support both
H.323 and SIP and work as equals. However, Peers may sometimes be referred to as Alternates.
About Clustering
LOCAL
ZONE
Traversal
Subzone
Default
Subzone
DNS
Zone
ENUM
Zone
Neighbor
Zone
Traversal
Client Zone
Subzone
Default
Zone
PEER 3PEER 2PEER 1 PEER 4
Cluster
Subzone
VCS CLUSTER
Cluster Subzone
When two or more VCSs are clustered together, a new subzone is created within the cluster’s Local
Zone. This is the Cluster Subzone, and any calls between two Peers in the Cluster will pass via this
Subzone during call setup. The Cluster Subzone is (like the Traversal Subzone) a virtual Subzone
used for call routing only, and endpoints can not register to this subzone. Once a call has been
established between two Peers, the Cluster Subzone will no longer appear in the call route and the
call will appear as having come from (or being routed to) the Default Subzone.
The two situations in which a call will pass via the Cluster Subzone are:
Calls between two endpoints registered to different peers in the Cluster.
•
For example, Endpoint A is registered in the Default Subzone to Peer 1. Endpoint B is also
registered in the Default Subzone, but to Peer 2. When A calls B, the call route is shown on Peer
1 as Default Subzone -> Cluster Subzone, and on Peer 2 as Cluster Subzone -> Default Subzone.
Calls received from outside the Cluster by one Peer, for an endpoint registered to another Peer.
•
For example, we have a single VCS for the Branch Ofce, which is neighbored to a Cluster of
4 VCSs at the Head Ofce. A user in the Branch Ofce calls Endpoint A in the Head Ofce.
Endpoint A is registered in the Default Subzone to Peer 1. The call is received by Peer 2, as
it has the lowest resource usage at that moment. Peer 2 then searches for Endpoint A within
the Cluster’s Local Zone, and nds that it is registered to Peer 1. Peer 2 then forwards the call
to Peer 1, which forwards it to Endpoint A. In this case, on Peer 2 the call route will be shown
as Branch Ofce -> Default Subzone -> Cluster Subzone, and on Peer 1 as Cluster Subzone ->
Default Subzone.