76
D14049.07
March 2010
Grey Headline
(continued)
TANDBERG
VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Introduction
Overview and
status
System
configuration
VCS
configuration
Zones and
neighbors
Clustering and
peers
Call
processing
Bandwidth
control
Firewall
traversal
Appendices
Applications
Maintenance
Dial plans
About dial plans
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
