AlternateGKs=1.2.3.4:1719:false:120:OpenH323GK
Default: N/A
We allow for existence of
another gatekeeper to provide redundancy. This is implemented in a
active-active manner. Actually, you might get into a (valid !) situation where
some endpoints are registered with the first and some are registered with the
second gatekeeper. You should even be able use the two gatekeepers in a
round_robin fashion for load-sharing (that's untested, though :-)). If you
read on, "primary GK" refers to the gatekeeper you're currently configuring
and "alternate GK" means the other one. The primary GK includes a field in the
RCF to tell endpoints which alternate IP and gatekeeper identifier to use. But
the alternate GK needs to know about every registration with the primary GK or
else it would reject calls. Therefore our gatekeeper can forward every RRQ to
an alternate IP address.
The AlternateGKs config
option specifies the fields contained in the primary GK's RCF. The first and
second fields of this string define where (IP, port) to forward to. The third
tells endpoints whether they need to register with the alternate GK before
placing calls. They usually don't because we forward their RRQs, so they get
registered with the alternate GK, too. The fourth field specified the priority
for this GK. Lower is better, usually the primary GK is considered to have
priority 1. The last field specifies the alternate gatekeeper's identifier.
SendTo=1.2.3.4:1719
Default: N/A
Although this information
is contained in AlternateGKs, you must still specify which address to forward
RRQs to. This might differ from AlternateGK's address, so it's a separate
config option (think of multihomed machines).
-Finny
