TANDBERG Gatekeeper - Manual (Page 21)

TANDBERG Gatekeeper User Guide
Page 21 of 105
When registering, the endpoint registers with one or more of the following:
 One or more H.323 IDs
 One or more E.164 aliases.
Users of other registered endpoints can then call the endpoint by using either the H.323 ID, a URI, an
E.164 alias, or one of the services.
It is recommended that you do not use aliases that reveal sensitive information. Due to the nature of
H.323, call setup information is exchanged in an unencrypted form.
By default, if you attempt to register an alias which has already been registered with the system, your
registration will be rejected. This helps you to identify when two users have a conflicting alias.
In some deployments an endpoint may frequently receive a new IP address, causing unwanted
registration rejections. When it tries to register, it may be rejected because the Gatekeeper still has a
registration from its old IP address. The Gatekeeper may be configured to allow an endpoint to overwrite
the old IP address. To do this, either issue the command:
xConfiguration Gatekeeper Registration ConflictMode:
or go to Gatekeeper Configuration > Restrictions and in the Policy section, from the Registration conflict
policy drop-down menu select Overwrite .
Consult the endpoint documentation for information on how to configure it with a Gatekeeper.
Note: When URI dialing is used to discover an endpoint, the URI used is based on either the H.323 ID
or the E.164 alias that the endpoint registered with. The local domain is then added to this. For
more information see URI Dialing (section 9).
4.6. Neighbor Gatekeepers
4.6.1. Neighboring and dial plans
As you start deploying more than one Gatekeeper or Border Controller, it is useful to neighbor the
systems together so that they can exchange information about registered endpoints. Each Gatekeeper
or Border Controller forms an H.323 zone and is responsible for the endpoints within that zone. There
are a number of ways this can be done, depending on the complexity of your system.
Flat dial plan
The simplest approach is to assign each endpoint a unique alias and divide the endpoint registrations
between the Gatekeepers and Border Controllers. Each Gatekeeper or Border Controller is then
configured with the addresses of all other Gatekeepers and Border Controllers. When a system receives
a call for an endpoint which is not registered with it, it will send out a Location Request to all the other
Gatekeepers and Border Controllers on the system. Whilst conceptually simple, this sort of flat dial plan
does not scale very well: adding or moving a Gatekeeper requires changing the configuration of every
Gatekeeper and Border Controller; one call attempt can result in a large number of location requests.
Structured dial plan
An alternative deployment would use a structured dial plan whereby endpoints are assigned an alias
based on the system they are registering with. Using E.164 aliases, each Gatekeeper or Border
Controller would be assigned an area code. When the Gatekeepers and Border Controllers are
neighbored together, each neighbor is configured with its corresponding area code as a prefix. That
neighbor will now 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 neighbors 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 Gatekeeper should be configured to strip prefixes before placing the
Location Request.
A structured dial plan will minimize the number of location requests issued when a call is attempted,
but, as described above, still requires a fully connected mesh of all Gatekeepers and Border Controllers
in your deployment. A hierarchical dial plan (see below) can simplify this.