Next Previous Contents

4. Using the Gatekeeper (Reference)

The behavior of the gatekeeper is completely determined by the command line options and configuration file. Some command line options may override the setting of the configuration file. For example, the option -l overrides the setting TimeToLive in the configuration file.

4.1 Command Line Options

Almost every option has a short and a long format, e.g., -c is the same as --config.

Basic

-h --help

Show all available options and quit the program.

-c --config filename

Specify the configuration file to use.

-s --section section

Specify which main section to use in the configuration file. The default is [Gatekeeper::Main].

-i --interface IP

Specify the interface (IP number) that the gatekeeper listens to. You should leave out this option to let the gatekeeper automatically determine the IP it listens to, unless you want the gatekeeper only binds to a specified IP.

-l --timetolive n

Specify the time-to-live timer (in seconds) for endpoint registration. It overrides the setting TimeToLive in the configuration file. See there for detailed explanations.

-b --bandwidth n

Specify the total bandwidth available for the gatekeeper. Without specifying this option, the bandwidth management is disable by default.

--pid filename

Specify the pid file, only valid for Unix version.

-u --user name

Run the gatekeeper process as this user. Only valid for Unix versions.

Gatekeeper Mode

The options in this subsection override the settings in the [RoutedMode] section of the configuration file.

-d --direct

Use direct endpoint call signalling.

-r --routed

Use gatekeeper routed call signalling.

-rr --h245routed

Use gatekeeper routed call signalling and H.245 control channel.

Debug Information

-o --output filename

Write trace log to the specified file.

-t --trace

Set trace verbosity. The more -t you add, the more verbose to output. For example, use -ttttt to set the trace level to 5.

4.2 Configuration File

The configuration file is a standard text file. The basic format is:

[Section String]
Key Name=Value String

Comments are marked with a hash (#) or a semicolon (;) at the beginning of a line.

The file complete.ini contains all available sections for the GnuGk. In most cases it doesn't make sense to use them all at once. The file is just meant as a collection of examples for many settings.

The configuration file can be changed at runtime. Once you modify the configuration file, you may issue reload command via status port, or send a signal HUP to the gatekeeper process on Unix. For example,

kill -HUP `cat /var/run/gnugk.pid`

Note Some section names in GnuGk 2.0.0 are named [RasSrv::*], while others are named [RasSvr::*]. This inconsistency confused users. In 2.0.1 all sections are corrected to [RasSrv::*]. If you upgrade from 2.0.0 or earlier version, remember to change the section names, or GnuGk will refuse to start.

Section [Gatekeeper::Main]

Most users will never need to change any of the following values. They are mainly used for testing or very sophisticated applications.

Section [LogFile]

This section defines log file related parameters. Currently it allows users to specify log file rotation options.

Section [RoutedMode]

Call signalling messages may be passwd in two ways. The first method is Direct Endpoint Call Signalling, in which case the call signalling messages are passed directly between the endpoints. The second method is Gatekeeper Routed Call Signalling. In this method, the call signalling messages are routed through the gatekeeper between the endpoints. The choice of which methods is used is made by the gatekeeper.

When Gatekeeper Routed call signalling is used, the gatekeeper may choose whether to route the H.245 control channel and logical channels.

Case I.

The gatekeeper doesn't route them. The H.245 control channel and logical channels are established directly between the endpoints.

Case II.

The H.245 control channel is routed between the endpoints through the gatekeeper, while the logical channels are established directly between the endpoints.

Case III.

The gatekeeper routes the H.245 control channel, as well as all logical channels, including RTP/RTCP for audio and video, and T.120 channel for data. In this case, no traffic is passed directly between the endpoints. This is usually called an H.323 Proxy, which can be regarded as an H.323-H.323 gateway.

This section defines the gatekeeper routed mode options (case I & II). The proxy feature is defined in the next section. All settings in this section are affected by reloading.

Section [Proxy]

The section defines the H.323 proxy features. It means the gatekeeper will route all the traffic between the calling and called endpoints, so there is no traffic between the two endpoints directly. Thus it is very useful if you have some endpoints using private IP behind an NAT box and some endpoints using public IP outside the box.

The gatekeeper can do proxy for logical channels of RTP/RTCP (audio and video) and T.120 (data). Logical channels opened by fast-connect procedures or H.245 tunnelling are also supported.

Note to make proxy work, the gatekeeper must have direct connection to both networks of the caller and callee.

Section [RoutingPolicy]

This section explains how the various possible routing policies within the gatekeeper work.

The incoming call requests can be routed using a number of routing providers:

If one policy does not match, the next policy is tried.

These policies can be applied to a number of routing request types, and routing input data. The different types are: ARQ, LRQ, Setup and Facility (with the callForwarded reason) There is also the general routing policy, which is kind of a default for the other types.

Example:

[RoutingPolicy]
h323_ID=dns,internal
002=neighbor,internal
Default=internal,neighbor,parent

When one of the messages is received which calls for a routing decision, all calls to an alias of the h323_ID type will be resolved using DNS. If DNS fails to resolve the alias, it is matched against the internal registration table. If a call is requested to an alias starting with 002, first the neighbours are checked and then the internal registration table. If the requested alias is not an h323_ID or an alias starting with 002, the default policy is used by querying the internal registration table, then the neighbours, and if that fails the parent.

For the ARQ, LRQ, Setup and Facility messages one would use the [RoutingPolicy::OnARQ], [RoutingPolicy::OnLRQ], [RoutingPolicy::OnSetup] and [RoutingPolicy::OnFacility] sections using the syntax explained above.

Section [GkStatus::Auth]

Define a number of rules who is allowed to connect to the status port. Whoever has access to the status port has full control over your gatekeeper. Make sure this is set correctly.

Section [RasSrv::GWPrefixes]

This section lists what E.164 numbers are routed to a specific gateway.

Format:

gw-alias=prefix[,prefix,...]

Note you have to specify the alias of the gateway. If a gateway registered with the alias, all numbers beginning with the prefixes are routed to this gateway. Special characters . and ! can be used here to match any digit and disable the prefix.

Example:

test-gw=02,03

Section [RasSrv::RewriteE164]

This section defines the rewriting rules for dialedDigits (E.164 number).

Format:

[!]original-prefix=target-prefix[,target-prefix,...]

If the number is beginning with original-prefix, it is rewritten to target-prefix. Multiple targets are possible. If the `!' flag precedes the original-prefix, the sense is inverted and the target-prefix is prepended to the dialed number. Special wildcard characters ('.' and '%') are available.

Example:

08=18888

If you dial 08345718, it is rewritten to 18888345718.

Example:

!08=18888

If you dial 09345718, it is rewritten to 1888809345718.

Option:

Section [RasSrv::GWRewriteE164]

This section describes rewriting the dialedDigits E.164 number depending on the gateway a call has come from or is being sent to. This allows for more flexible manipulation of the dialedDigits for routing etc. In combination with the RasSrv::RewriteE164 you can have triple stage rewriting:

Call from "gw1", dialedDigits 0867822
                |
                |
                V
Input rules for "gw1", dialedDigits now 550867822
                |
                |
                V
Global rules, dialedDigits now 440867822
                |
                |
                V
Gateway selection, dialedDigits now 440867822, outbound gateway "gw2"
                |
                |
                V
Output rules for "gw2", dialedDigits now 0867822
                |
                |
                V
Call to "gw2", dialedDigits 0867822

Format:

gw-alias=in|out=[!]original-prefix=target-prefix[;in|out...]

If the call matches the gateway, the direction and begins with original-prefix it is rewritten to target-prefix. If the `!' flag precedes the original-prefix, the sense is inverted. Special wildcard characters ('.' and '%') are available. Multiple rules for the same gateway should be seperated by ';'.

Example:

gw1=in=123=321

If a call is received from "gw1" to 12377897, it is rewritten to 32177897 before further action is taken.

Section [RasSrv::PermanentEndpoints]

In this section you can put endpoints that don't have RAS support or that you don't want to be expired. The records will always keep in registration table of the gatekeeper. However, You can still unregister it via status port. Special characters . and ! can be used with prefixes here to match any digit and disable the prefix.

Format:

IP[:port]=alias[,alias,...;prefix,prefix,...]

Example:

For gateway,

10.0.1.5=Citron;009,008
For terminal,
10.0.1.10:1720=700

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 ``*'' prefix. More than one prefix can be specified. You can use special characters ``.'' and ``!'' to do wildcard matching and disable a specific prefix.

Conversely, the gatekeeper will only reply to LRQs sent from neighbors defined in this section. If you specify an empty prefix, no LRQ will be sent to that neighbor, but the gatekeeper will accept LRQs from it. By the empty prefix it is meant a single semicolon appended to the neighbor entry. Example:

GK1=192.168.0.5;

If you skip the semicolon, LRQs will be always sent to this neighbor.

The password field is used to authenticate LRQs from that neighbor. See section [Gatekeeper::Auth] for details.

Neighbor handling has changed significantly from version 2.0 to version 2.2. Neighbors can be specified now in two ways - the old one and the new one.

Entry in the old format:

GKID=ip[:port;prefixes;password;dynamic]

Example:

GK1=192.168.0.5;*
GK2=10.0.1.1:1719;035,036;gk2
GK3=gk.citron.com.tw;;gk3;1

Entry in the new format:

GKID="GnuGK" | "CiscoGK" | "ClarentGK" | "GlonetGK"

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 new format specifies in [RasSrv::Neighbors] section only gatekeeper types and configuration for each neighbor is placed in a separate section.

Section [RasSrv::LRQFeatures]

Defines some features of LRQ and LCF.

Section [Neighbor::...]

Sections starting with [Neighbor:: are for neighbor specific configuration.

Section [RasSrv::RRQFeatures]

Section [RasSrv::ARQFeatures]

Section [CallTable]

Section [Endpoint]

The gatekeeper can work as an endpoint by registering with another gatekeeper. With this feature, you can easily build gatekeeper hierarchies. The section defines the endpoint features for the gatekeeper.

Section [Endpoint::RewriteE164]

Once you specify prefix(es) for your gatekeeper endpoint, the parent gatekeeper will route calls with dialedDigits beginning with that prefixes. The child gatekeeper can rewrite the destination according to the rules specified in this section. By contrast, when an internal endpoint calls an endpoint registered to the parent gatekeeper, the source will be rewritten reversely.

Format:

external prefix=internal prefix

For example, if you have the following configuration,

                        [Parent GK]
                        ID=CitronGK
                        /         \
                       /           \
                      /             \
                     /               \
                [Child GK]          [EP3]
                ID=ProxyGK          E164=18888200
                Prefix=188886
                /       \
               /         \
              /           \
           [EP1]         [EP2]
           E164=601      E164=602

With this rule:

188886=6

When EP1 calls EP3 by 18888200, the CallingPartyNumber in the Q.931 Setup will be rewritten to 18888601. Conversely, EP3 can reach EP1 and EP2 by calling 18888601 and 18888602, respectively. In consequence, an endpoint registered to the child GK with prefix '6' will appear as an endpoint with prefix '188886', for endpoints registered to the parent gatekeeper.

The section does not relate to the section RasSrv::RewriteE164, though the later will take effect first.

Section [Gatekeeper::Auth]

The section defines the authentication mechanism for the gatekeeper.

Syntax:

authrule=actions

 <authrule> := SimplePasswordAuth | AliasAuth | PrefixAuth | RadAuth | RadAliasAuth | ...
 <actions>  := <control>[;<ras>|<q931>,<ras>|<q931>,...]
 <control>  := optional | required | sufficient
 <ras>      := GRQ | RRQ | URQ | ARQ | BRQ | DRQ | LRQ | IRQ
 <q931>     := Setup | SetupUnreg

A rule may results in one of the three codes: ok, fail, pass. There are also three ways to control a rule:

Currently supported modules:

You can also configure a rule to check only for some particular RAS messages. The following example configures SimplePasswordAuth as an optional rule to check RRQ and ARQ. If an RRQ is not checked (not contains tokens or cryptoTokens fields), it is checked by AliasAuth. The default is to accept all requests.

Example 1:

SimplePasswordAuth=optional;RRQ,ARQ
AliasAuth=sufficient;RRQ

The example below authenticates all calls, checking signalling Setup message details, using RadAliasAuth module.

Example 2:

RadAliasAuth=required;Setup
default=allow

This example checks endpoint registrations (RRQ) and call admissions (ARQ) either by means of username/password (RadAuth) or alias/IP (RadAliasAuth). Additionally, if the call is from an unregistered endpoint (and therefore no RRQ or ARQ authentication has been performed), Setup message authentication using RadAliasAuth takes place (SetupUnreg).

Example 3:

RadAuth=optional;RRQ,ARQ
RadAliasAuth=required;RRQ,ARQ,SetupUnreg
default=allow

Section [SimplePasswordAuth]

The section defines the userid and password pairs used by SimplePasswordAuth module. Use `make addpasswd' to generate the utility addpasswd.

Usage:

addpasswd config userid password

Options:

Section [SQLPasswordAuth]

Authenticate H.235 enabled endpoints using passwords stored in the SQL database. This section defines SQL driver to use, SQL database connection parameters and the query to use to retrieve passwords.

Section [MySQLPasswordAuth]

Define the MySQL database, table and fileds to retrieve the userid and password. This is obsolete, use [SQLPasswordAuth] instead.

The SQL command will be issused:

SELECT $DataField FROM $Table WHERE $KeyField = %id [AND $ExtraCriterion]

Section [RasSrv::RRQAuth]

Specify the action on RRQ reception (confirm or deny) for AliasAuth module. The first alias (this will mostly be an H323ID) of the endpoint to register is looked up in this section. If a parameter is found the value will apply as a rule. A rule consists of conditions separated by "&". A registration is accepted when all conditions apply.

Syntax:

<authrules> :=  empty  |  <authrule> "&" <authrules>

  <authrule>  := <authtype> ":" <authparams>
  <authtype>  := "sigaddr" | "sigip"
  <autparams> := [!&]*

The notation and meaning of <authparams> depends on <authtype>:

Section [SQLAliasAuth]

Authenticate endpoints using rules stored in the SQL database (the rules conform to the format defined in the [RasSrv::RRQAuth] section). This section defines SQL driver to use, SQL database connection parameters and the query to use to retrieve the patterns.

Section [MySQLAliasAuth]

Define the MySQL database, table and fileds to retrieve a pattern for an alias. This section is OBSOLETE and provided only for backward compatibility. Please use [SQLAliasAuth] instead.

The SQL command will be issused:

SELECT $DataField FROM $Table WHERE $KeyField = %alias [AND $ExtraCriterion]

Section [PrefixAuth]

The section defines the authentication rule for PrefixAuth module. Currently, only ARQs and LRQs can be authorized by this module.

First, a most specific prefix is selected according to the destinationInfo field of the received request. Then the request is accepted or rejected according to the matched rules with most specific netmask. If no matched prefix is found, and the default option is specified, the request is accepted or rejected according to that. Otherwise it is rejected or passed to next authentication module according to the module requirement.

Format:

prefix=authrule[|authrule|...]

Syntax:

<authrule> :=  <result> <authrule>

  <result>    := deny | allow
  <authrule>  := [!]ipv4:<iprule> | [!]alias:<aliasrule>

Where <iprule> can be specified in decimal dot notation or CIDR notation, <aliasrule> is expressed in regular expression. If the `!' flag precedes the rule, the sense is inverted.

Example:

555=deny ipv4:10.0.0.0/27|allow ipv4:0/0
5555=allow ipv4:192.168.1.1|deny ipv4:192.168.1.0/255.255.255.0
86=deny !ipv4:172.16.0.0/24
09=deny alias:^188884.*
ALL=allow ipv4:ALL

In this configuration, all endpoints except from network 10.0.0.0/27 are allow to call prefix 555 (except 5555). Endpoints from 192.168.1.0/24 are not allowed to call prefix 5555, except 192.168.1.1. Endpoints not from 172.16.0.0/24 are denied to call prefix 86. Endpoints having an alias beginning with 188884 are not allowed to call prefix 09. All other situations are allowed.

Section [RadAuth]

This section defines configuration settings that enable RADIUS authentication based on H.235 CATs (Cisco Access Tokens) present in RRQ, ARQ RAS requests and Q.931 Setup messages.

Section [RadAliasAuth]

This section defines configuration settings that enable RADIUS authentication based on endpoint aliases and/or IP adresses present in RRQ RAS requests, ARQ RAS request or Q.931 Setup request. This authentication scheme is useful both for endpoints registered at the gatekeeper (ARQ,RRQ) and calls from unregistered endpoints (Setup).

Section [GkLDAP::LDAPAttributeNames]

This section defines which LDAP attribute names to use.

Section [GkLDAP::Settings]

This section defines the LDAP server and standard LDAP client operating parameters to be used.

Section [Gatekeeper::Acct]

The section defines a list of modules that will be performing accounting. The accounting is for logging gatekeeper on/off events and call start/stop/update events. Each accounting module logs received events to a module specific storage. Such storage can be a plain text file or a RADIUS server and many more. The configuration is very similar to the one for gatekeeper authentication (see [Gatekeeper::Auth]).

All CDRs are also sent to the status port and can be used by external applications.

Syntax:

acctmod=actions

 <acctmod> := FileAcct | RadAcct | SQLAcct | ...
 <actions> := <control>[;<event>,<event>,...]
 <control> := optional | required | sufficient | alternative
 <event>   := start | stop | connect | update | on | off

The event list tells the gatekeeper, which events should trigger logging with the given accounting module (if an event type is supported by the module): An event logging by a module may results in one of the three result codes: ok, fail, next. Accounting modules can be stacked to log events by multiple modules or to create failover setups. control flag for each module, along with result codes, define what is the final status of the event processing by the whole module stack. If the final result is failure, some special actions may take place. Currently, if a call start event logging fails, the call is disconnected immediatelly. The following control flags are recognized:

Currently supported accounting modules:

The sample configuration #1 (try to log call start/stop with RADIUS server, and always write a CDR to a text file):

Example:

RadAcct=optional;start,stop
FileAcct=required

The sample configuration #2 (try to log call start/stop with RADIUS server, if it fails use a CDR log file):

Example:

RadAcct=alternative;start,stop
FileAcct=sufficient;stop
default=accept

The default rule is required here to prevent calls from being rejected because of RadAcct start event logging failure. If RadAcct returns fail return code, it is passed down to FileAcct module. FileAcct module does not support start events, so it returns next return code. If there were no the default rule, the final status would be failure, because no module has been able to log the event.

The sample configuration #3 (always log call start and stop events with RADIUS server, if it fails for call stop event, use a CDR file to store call info):

Example:

RadAcct=alternative;start,stop
FileAcct=sufficient;stop
default=fail;start

The default rule is optional here. If RadAcct returns fail return code for start event, the code is passed down to FileAcct module. FileAcct module does not support start events, so it returns next return code. The default rule ensures, that the call is disconnected if call start event could not has been logged with RadAcct. But we want to store a CDR in a text file in case the RADIUS server is down when the call disconnects, so we can fetch call duration into a billing system later.

Section [FileAcct]

This accounting module writes CDR lines to a specified text file. The CDR format can be a standard one (the same as displayed by the status interface) or a customized one (using parametrized query string).

Section [RadAcct]

This accounting module sends accounting data to a RADIUS server. Module configuration is almost the same as for RADIUS authenticators (see [RadAuth] and [RadAliasAuth] for more details on the parameters).

Section [SQLAcct]

This accounting module stores accounting information directly to an SQL database. Many configuration settings are common with other SQL modules.

Section [NATedEndpoints]

The gatekeeper can automatically detect whether an endpoint is behind NAT. However, if the detection fails, you can specify it manually in this section.

Format:

alias=true,yes,1,...

Example:

Specify an endpoint with alias 601 is behind NAT.

601=true

Section [CTI::Agents]

This section allows the configuration of a so called virtual queues to allow inbound call distribution by an external application via the status port. A virtual queue has an H.323 alias that can be called like an endpoint.

Upon arrival of an ARQ on a virtual queue, the gatekeeper signals a RouteRequest on the status port and waits for an external application to respond with either a RouteReject (then the ARQ will be rejected) or with RouteToAlias/RouteToGateway which leads to the ARQ being rewritten so the call will be routed to the alias (eg. call center agent) specified by the external application.

If no answer is received after a timeout period, the call is terminated.

You can specify virtual queues in three ways:

See the monitoring section for details on the messages and responses.

4.3 Per-Endpoint Configuration Settings

In addition to the standard configuration file options, per-endpoint configuration settings can be specified in the config file. The syntax is as follows:

[EP::ALIAS]
Key Name=Value String

ALIAS is replaced with an actual alias for an endpoint the settings should apply to. Currently, the following options are recognized:

Example:

[RasSrv::PermanentEndpoints]
192.168.1.1=gw1;48
192.168.1.2=gw2;48,!4850,!4860,!4869,!4888

[EP::gw1]
Capacity=60
GatewayPriority=1

[EP::gw2]
Capacity=30
GatewayPriority=2

In this example, calls will be sent to the gateway gw1 until its capacity is fully utilized (60 concurrent calls) and then to the gateway gw2.


Next Previous Contents