If the destination of an ARQ is unknown, the gatekeeper sends LRQs to
its neighbors to ask if they have the destination endpoint.
A neighbor is selected if one of its prefixes matches the destination
or it has the ``*
'' prefix. More than one prefix may be specified.
You can use special characters ``.
'' to do wildcard
matching and ``!
'' to disable a specific prefix.
The gatekeeper will only reply to LRQs sent from neighbors defined in this section. If you specify an empty SendPrefixes entry, no LRQ will be sent to that neighbor, but the gatekeeper will accept LRQs from it.
The password
field is used to authenticate LRQs from that neighbor.
See section
[Gatekeeper::Auth] for details.
Whether a call is accepted from a neighbor also depends on the AcceptNeighborsCalls switch in the [RoutedMode] section.
GKID="GnuGk" | "CiscoGk" | "ClarentGk" | "GlonetGk"
The gatekeeper types have the following characteristics:
Generic
GnuGk
CiscoGk
ClarentGk
GlonetGk
[RasSrv::Neighbors]
GK1=CiscoGk
GK2=GnuGk
[Neighbor::GK1]
GatekeeperIdentifier=GK1
Host=192.168.1.1
SendPrefixes=02
AcceptPrefixes=*
ForwardLRQ=always
[Neighbor::GK2]
GatekeeperIdentifier=GK2
Host=192.168.1.2
SendPrefixes=03,0048
AcceptPrefixes=0049,001
ForwardHopCount=2
ForwardLRQ=depends
The [RasSrv::Neighbors]
section is only used to specify the gatekeeper type. The configuration for each neighbor is placed in a separate section.
Defines some features of LRQ and LCF.
NeighborTimeout=1
2
Timeout value in seconds to wait for responses from neighbors. If no neighbor responds before the timeout, the gatekeeper will reply with an ARJ to the endpoint sending the ARQ.
SendRetries=4
2
Number of tries to send LRQ to neighbors. If there is no response from neighbors after retries timeout, the gatekeeper will reply with a LRJ to the endpoint sending the LRQ.
ForwardHopCount=2
N/A
If the gatekeeper receives a LRQ that the destination is unknown it may forward this message to its neighbors.
When the gatekeeper receives a LRQ and decides that the message should be forwarded on to another gatekeeper, it first decrements hopCount field of the LRQ. If hopCount has reached 0, the gatekeeper shall not forward the message. This option defines the number of gatekeepers through which a LRQ may propagate. Note that it only affects the sender of LRQ, not the forwarder. This setting can be overridden via the configuration section for a particular neighbor.
AcceptForwardedLRQ=1
1
Whether to accept an LRQ forwarded from neighbors. This setting can be overridden with configuration of a particular neighbor.
ForwardResponse=0
0
If the gatekeeper forwards a received LRQ message it can decide either to receive the LCF response or to let it travel back directly to the LRQ originator. Set this option to 1 if the gatekeeper needs to receive LCF messages for forwarded LRQs. This setting can be overridden with configuration of a particular neighbor.
ForwardLRQ=always | never | depends
depends
This settings determines whether the received LRQ should be forwarded
or not. always
forwards LRQ unconditionally, never
blocks LRQ
forwarding, depends
tells the gatekeeper to forward LRQ only if its
hop count is greater than 1. This setting can be overridden with configuration
of a particular neighbor.
AcceptNonNeighborLRQ=1
0
Whether to accept a LRQ forwarded from parties not defined as Neighbors. This can be used with SRV routing policy to place calls to third party gatekeepers. This should be used in conjunction with a LRQ Authentication policy.
AcceptNonNeighborLCF=1
0
This setting disables matching of the LRQ responder's IP address and specified neighbor IP addresses in order to accept LCF message responses from any IP address. This has primary importance when a multiple level gatekeeper hierarchy is used without routed Q.931 signaling. As a minimal security, only LRQ/LCF sequence numbers will be checked accordingly. This feature is required by the national gatekeepers connected to the Global Dialing Scheme (GDS), see http://www.vide.net/help/gdsintro.shtml for more information. WARNING: Enabling receiving LCF from other than the LRQ destination IP is a significant security risk. Use this setting with extreme caution.
SendRIP=9000
0
Send a RequestInProgress (RIP) message with this delay value after receiving an LRQ. This switch can be used to extend the duration the caller will wait for an answer. No RIP is sent when the delay ist set to 0.
PingAlias=gatekeeper-monitoring-check
N/A
Predefined Alias used with LRQ pinging. Capturing the Alias used for PING helps reduce gatekeeper resources processing the LRQ. Feature used by VCS in GDS dialing schema. Feature currently only accepts pings and does not send any.
EnableLanguageRouting=1
0
Whether to compare users language settings in determining routing requests.
Sections starting with [Neighbor::
are specific for one neighbor. If
you define a [Neighbor::...] section, the default values of all
settings in
[RasSrv::LRQFeatures] will be applied to
this neighbor. You may override the global defaults through configuration options in
each neighbor-specific section.
GatekeeperIdentifier=GKID
N/A
Gatekeeper identifier for this neighbor. If this option is not specified,
the identifier is taken from the second part of the Neighbor::
section name.
Host=192.168.1.1
N/A
An IP address for this neighbor.
Password=secret
N/A
A password to be used to validate crypto tokens received in incoming LRQs and SCIs. Encrypted if Keyfilled= is set, plain text otherwise.
AuthUser=Foo
GKID
The user name to be used to validate crypto tokens received in incoming LRQs and SCIs. The default value is the gatekeeper identifier for this neighbor (see above).
Dynamic=0
0
1 means that the IP address for this neighbor can change.
SendPrefixes=004,002:=1,001:=2
N/A
A list of prefixes that this neighbor expects to receive LRQs for.
If '*' is specified, LRQs will always be sent to this neighbor.
A priority can be given to each prefix for each neighbor (using := syntax),
so in case of multiple LCF received from multiple neighbor, the one
with the highest priority will be selected to route the call.
One can also direct the gatekeeper to send LRQ to this neighbor
based on an alias type:
SendPrefixes=h323_ID,dialedDigits,001
SendIPs=192.168.0.0/16,172.16.0.0/12
N/A
Send calls dialed by IP to this neighbor. You can specify a list of networks with optional netmask. You can also put a ! in front of the network for negation. Special values are "*" to send all IP calls, "private" to send all IPv4 private networks and "public" to send all public IPv4 adresses to this neighbor. If one of the networks matches the dialed IP, the neighbor is selected.
If the call comes from a registered endpoint, this endpoint must support canMapAlias for ARQs.
SendAliases=4526354,2000-2010,frank
N/A
A list of specific aliases this neighbor expects to receive LRQs for. For E.164 numbers, ranges can be specified.
AcceptPrefixes=*
*
A list of prefixes that GnuGk will accept in LRQs received
from this neighbor. If '*' is specified, all LRQs will be accepted from this neighbor.
One can also direct the gatekeeper to accept LRQ from this neighbor
based on an alias type:
AcceptPrefixes=dialedDigits
ForwardHopCount=2
N/A
If the gatekeeper receives an LRQ that the destination is either unknown, it may forward this message to its neighbors. When the gatekeeper receives an LRQ and decides that the message should be forwarded on to another gatekeeper, it first decrements hopCount field of the LRQ. If hopCount has reached 0, the gatekeeper shall not forward the message. This options defines the number of gatekeepers through which an LRQ may propagate. Note it only affects the sender of LRQ, not the forwarder.
AcceptForwardedLRQ=1
1
Whether to accept an LRQ forwarded from this neighbor.
ForwardResponse=0
0
If the gatekeeper forwards received LRQ message it can decide either to receive the LCF response or to let it travel back directly to the LRQ originator. Set this option to "1" if the gatekeeper needs to receive LCF messages for forwarded LRQs.
ForwardLRQ=always | never | depends
depends
This settings determines whether the received LRQ should be forwarded
or not. always
forwards LRQ unconditionally, never
blocks LRQ
forwarding, depends
tells the gatekeeper to forward LRQ only if its
hop count is greater than 1.
H46018Client=1
0
Enable H.460.18 keep-alive messages to this neighbor and act as a traversal client.
H46018Server=1
0
Act as a traversal server for another gatekeeper which is configured as traversal client.
No two neighbors for which we are acting as traversal server should have the same AuthUser name. Since the IP of the traversal client can be unknown or changing, the user name is used to update the IP for this neighbor.
SendPassword=secret
N/A
EXPERIMENTAL: The password to send to the neighbor (right now only used for H.460.18 SCI). Encrypted if Keyfilled= is set, plain text otherwise.
SendAuthUser=Foo
own GK-ID
The user name (gatekeeprID) to be used to send crypto tokens to this neighbor (right now only used for H.460.18 SCI). The default value is this gatekeeper's ID.
UseTLS=1
0
Use TLS (transport layer security) with this neighbor. See also [TLS] section.
To configure a traversal zone with a Tandberg VCS, add a Zone of type "Traversal client" in the VCS.
The user name and password configured in the VCS should be set as AuthUser= and Password= in the [Neighbor::..] section. The password must be encoded with the addpasswd tool if the Keyfilled= switch is used, otherwise it is entered as plain text in the config. Please note that for any password authentication to work, both systems must have accurate and synchronized time, so it is strongly recommended that you configure NTP.
Enable H.323 in the VCS settings, set the Protocol to H.460.18 (not Assent) and the port to 1719.
Add the IP of your GnuGk server as the Peer 1 address in the VCS.
Enable H.460.18 in your GnuGk config with EnableH46018=1 in the [RoutedMode] section. Set H46018Client=0 and H46018Server=1 in the [Neighbor::..] section. If H.460.18 is globally enabled, GnuGk will automatically detect that a neighbor is acting like a H.460.18 traversal zone client and it needs to act as a traversal server. But since traversal clients may come from unknown or changing IPs, setting the H46018Server flag explicitly allows GnuGk to update the client's IP on the first keepAlive SCI message.
[RoutedMode]
EnableH46018=1
[RasSrv::Neighbors]
VCSClient=Generic
[Neighbor::VCSClient]
GatekeeperIdentifier=FooVCS
Host=192.168.1.1
SendPrefixes=02
AcceptPrefixes=*
H46018Client=0
H46018Server=1
AuthUser=clientuser
Password=clientpw
To configure a traversal zone with a Tandberg VCS, add a Zone of type "Traversal server" in the VCS. When functioning as a traversal server, the VCS usually uses a different port, so make sure you add the port to the Host switch.
Enable H.323 in the VCS settings, set the Protocol to H.460.18 (not Assent) and select a port (you can't use 1719!). You must specify this port in your GnuGk config for this neighbor. Set a username and password in the VCS and put them into SendAuthUser= and SendPaswword= in your GnuGk config.
In the GnuGk config, set EnableH46018=1 in [RoutedMode] and set H46018Client=1 in the [Neighbor::..] section.
Please note that for any password authentication to work, both systems must have accurate and synchronized time, so it is strongly recommended that you configure NTP.
[RoutedMode]
EnableH46018=1
[RasSrv::Neighbors]
VCSServer=Generic
[Neighbor::VCSServer]
;from unknown IP
Host=211.211.10.10:9004
SendPrefixes=*
AcceptPrefixes=*
H46018Client=1
H46018Server=0
SendAuthUser=serveruser
SendPassword=serverpw