As you start deploying more than one VCS, it is useful to neighbor the systems together so that
they can query each other about their registered endpoints. Before you start, you should consider
how you will structure your dial plan. This will determine the aliases assigned to the endpoints, and
the way in which the VCSs are neighbored together. The solution you choose will depend on the
complexity of your system. Some possible options are described in the following sections.

Flat dial plan

The simplest approach is to assign each endpoint a unique alias and divide the endpoint
registrations between the VCSs. Each VCS is then configured with all the other VCS as neighbor
zones. When one VCS receives a call for an endpoint which is not registered with it, it will send out a
Location Request to all the other neighbor VCSs.
While conceptually simple, this sort of flat dial plan does not scale very well. Adding or moving a
VCS requires changing the configuration of every VCS, and one call attempt can result in a large
number of location requests. This option is therefore most suitable for a deployment with just one
or two VCSs plus its peers.

Structured dial plan

An alternative deployment would use a structured dial plan where endpoints are assigned an alias
based on the system they are registering with.
If you are using E.164 aliases, each VCS would be assigned an area code. When the VCSs are
neighbored together, each neighbor zone would have an associated search rule configured with its
corresponding area code as a prefix (a Mode of Alias Pattern Match and a Pattern type of Prefix).
That neighbor would then only be queried for calls to numbers which begin with its prefix.
In a URI based dial plan, similar behavior may be obtained by configuring search rules for each
neighbor with a suffix to match the desired domain name.
It may be desirable to have endpoints register with just the subscriber number -- the last part of the
E.164 number. In that case, the search rule could be configured to strip prefixes before sending the
query to that zone.
A structured dial plan minimizes the number of queries issued when a call is attempted. However,
it still requires a fully connected mesh of all VCSs in your deployment. A hierarchical dial plan can
simplify this.

Hierarchical dial plan

In this type of structure one VCS is nominated as the directory for the deployment, and all other
VCSs are neighbored with it alone.
The directory VCS is configured with:

•

each VCS as a neighbor zone

•

search rules for each zone that have a Mode of Alias Pattern Match and the target VCS's prefix
(as with the structured dial plan) as the Pattern string

Each VCS is configured with:

•

the directory VCS as a neighbor zone

•

a search rule with a Mode of Any Alias and a Target zone of the directory VCS

There is no need to neighbor the VCSs with each other. Adding a new VCS now only requires
changing configuration on the new VCS and the directory VCS.
However, failure of the directory VCS in this situation could cause significant disruption to
communications. Consideration should be given to the use of

Clustering

for increased resilience.

For H.323 calls, if Optimal

call routing

is enabled you must ensure that all search rules are

configured with a Source of Any.
If the Source is configured to All zones (the default), H.323 calls will fail to connect. This is

because the H.323 SETUP message, having followed the optimized route established by the original
LRQ or ARQ, will appear to the target VCS as coming from an unknown zone. SIP calls, however, are
successfully routed if the search rule Source is Any (because in SIP the search and call setup is
combined into one message).

Structuring your dial plan