This is the manual for GNU Gatekeeper 4.8.
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

Download GnuGk    Join the community    Get support

The GNU Gatekeeper Manual Chapter 10

10. Neighbor Configuration

10.1 Section [RasSrv::Neighbors]

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.
  • 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.

10.2 Section [RasSrv::LRQFeatures]

Defines some features of LRQ and LCF.

  • NeighborTimeout=1
    Default: 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.

    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.

  • 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: 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
    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://community.jisc.ac.uk/library/videoconferencing-booking-service/global-dialing-scheme-explained 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 ist 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.

10.3 Section [Neighbor::...]

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 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
    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.

  • AcceptForwardedLRQ=1
    Default: 1

    Whether to accept an LRQ forwarded from this neighbor.

  • ForwardResponse=0
    Default: 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
    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.

10.4 Configuring a Traversal Zone with GnuGk as Traversal Server

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

10.5 Configuring a Traversal Zone with GnuGk as Traversal Client

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



Last updated: 16. Nov 2017
Page maintained by Jan Willamowius