|
This is the manual for GNU Gatekeeper 5.13.
A manual for your version is in your GnuGk download archive.
A PDF version can be found in the download section.
Chapters:
Contents ·
Introduction ·
Installation ·
Getting started ·
Basic Config ·
Routed Mode & Proxy ·
Routing ·
RAS Config ·
Authentication ·
Accounting ·
Neighbors ·
Per Endpoint Config ·
Advanced Config ·
Monitoring ·
Advanced Topics
The GNU Gatekeeper Manual Chapter 10
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
For neighbors from any H.323 compliant vendor. (This setting is identical to 'GnuGk'.)
GnuGk
When in doubt, use the GnuGk gatekeeper type. This also activates H.460.23 / H.460.24.
CiscoGk
GnuGk will pretend to be a Cisco gatekeeper and send fake manufacturer data. Use only for really old Cisco gatekeepers.
ClarentGk
Clarent gatekeeper can't decode nonStandardData in LRQs, so GnuGk will filter it out.
GlonetGk
Limited support for LRQ forwarding.
- Example:
[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
Default: 5
Timeout value in 10th of a second 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.
This timout is applied to each retry (see below).
SendRetries=4
Default: 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
Default: 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.
This setting also limits the hop count for forwarded LRQs.
AcceptForwardedLRQ=1
Default: 1
Whether to accept an LRQ forwarded from neighbors.
This setting can be overridden with configuration
of a particular neighbor.
ForwardResponse=0
Default: 1
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
Default: 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
Default: 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
Default: 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
https://en.wikipedia.org/wiki/Global_Dialing_Scheme
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
Default: 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 is set to 0.
EnableLanguageRouting=1
Default: 0
Whether to compare users language settings in determining routing requests.
PingAlias=my-ping
Default: gatekeeper-monitoring-check
Alias used for LRQ pinging. LRQs received with this alias will be processed a bit faster than reqular requests.
This feature is also used by VCS in GDS dialing schema. Setting the alias alone will not turn on the sending of pings.
SendLRQPing=1
Default: 0
When enabled, GnuGk will periodically ping all its neighbors with a LRQ. If the neighbor doesn't respond with
a LRQ or LRJ withing the NeighborTimeout, the neighbor is disabled and won't be used for routing until the
next LRQ ping succeeds. Skipping disabled neighbors can speed up routing in some configurations.
You can configure the alias in the LRQ with the PingAlias switch.
LRQPingInterval=30
Default: 60
Interval to be used for sending LRQ pings.
LoopDetection=1
Default: 0
Reject LRQs for calls that GnuGk has already seen recently. Use this to avoid call loops and
LRQ storms when you have multiple gatekeepers who forward all calls to each other.
This feature works only with neighbors of type 'GnuGk' or 'Generic'.
LoopDetectionExpireTime=120
Default: 60
Time duration in seconds how long to store data about calls GnuGk has seen.
LoopDetectionReprocessLCFs=1
Default: 0
Don't cache any LCFs in the loop detection. Use if cached LCFs with incorrect data (for another endpoint) break the routing.
PreserveDestination=1
Default: 0
Don't rewrite the destinationInfo when resolving LRQs with the SRV policy
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
Default: 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
Default: N/A
An IP address for this neighbor.
Password=secret
Default: 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
Default: 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
Default: 0
1 means that the IP address for this neighbor can change.
SendPrefixes=004,002:=1,001:=2
Default: 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
Default: 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 addresses 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
Default: N/A
A list of specific aliases this neighbor expects to receive LRQs for.
For E.164 numbers, ranges can be specified.
AcceptPrefixes=*
Default: *
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
Default: 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.
This setting also limits the hop count for forwarded LRQs.
AcceptForwardedLRQ=1
Default: 1
Whether to accept an LRQ forwarded from this neighbor.
ForwardResponse=0
Default: 1
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 should to receive LCF
messages for forwarded LRQs.
ForwardLRQ=always | never | depends
Default: 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
Default: 0
Enable H.460.18 keep-alive messages to this neighbor and act as a traversal client.
H46018Server=1
Default: 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
Default: N/A
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
Default: 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
Default: 0
Use TLS (transport layer security) with this neighbor. See also
[TLS] section.
SendLRQPing=1
Default: 0
Enable LRQ ping only for this neighbor.
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.
- Example:
-
[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.
- Example:
-
[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
Next
Previous
Contents
Chapters:
Contents ·
Introduction ·
Installation ·
Getting started ·
Basic Config ·
Routed Mode & Proxy ·
Routing ·
RAS Config ·
Authentication ·
Accounting ·
Neighbors ·
Per Endpoint Config ·
Advanced Config ·
Monitoring ·
Advanced Topics
|
