OpenH323 Gatekeeper - The GNU Gatekeeper

Maintainer of this manual: Chih-Wei Huang <cwhuang@linux.org.tw>

v2.0.3, 20 February 2003

This is the User Manual for how to compile, install, configure and monitor OpenH323 Gatekeeper - The GNU Gatekeeper.

1. Introduction

1.1 About

OpenH323 Gatekeeper - The GNU Gatekeeper is an open-source project that implements an H.323 gatekeeper. A gatekeeper provides call control services to the H.323 endpoints. It is an integral part of most usefull internet telephony installations that are based on the H.323 standard.

According to Recommendation H.323, a gatekeeper shall provide the following services:

The GNU Gatekeeper implements most of these functions based on the OpenH323 protocol stack.

Recommendation H.323 is an international standard published by the ITU. It is a communications standard for audio, video, and data over the Internet. See also Paul Jones' primer on H.323.

For a detailed description of what a gatekeeper does, see here.

1.2 Copyright

It is covered by the GNU General Public License (GNU GPL). In addition to that, we explicitely grant the right to link this code to the OpenH323 and OpenSSL library.

Generally speaking, the GNU GPL allows you to copy, distribute, resell or modify the softwares, but it requires that all derived works must be published under GNU GPL also. That means that you must publish full source for all extensions to the gatekeeper and for all programs you include the gatekeeper into. See the file COPYING for details.

If that's not what you want, you must interface to the gatekeeper through the status thread and communicatie via TCP with it. That way you only have to integrate the basic funtionality into the gatekeeper (and provide source for that) and can keep other parts of your application private.

1.3 Name

The formal name of this project is OpenH323 Gatekeeper - The GNU Gatekeeper, shortly OpenH323GK or GnuGK. Please don't confuse it with other gatekeeper projects.

There are several open-source gatekeeper projects based on the OpenH323 protocol stack.

To have different gatekeepers with very similar names is really confusing for most users. Since our "OpenH323 Gatekeeper" was the first on the scene, it is not our fault that others have chosen similar names. But to make the destinction a little more clear without confusing people even more, we have decided to give the project a subtitle "OpenH323 Gatekeeper - The GNU Gatekeeper" and start using gnugk as name for executables.

1.4 Features

The version 2.0.3 is a bugfix release, plus a little enhancement:

The new features added to version 2.0.2 are:

Of course, the major functions in version 2.0 are also included:

1.5 Download

The newest stable and a development version are available at the download page.

The very latest source code is in the CVS at Sourceforge ( Web-GUI). Beware - that's the bleeding edge.

You can also download executables from Sourceforge. Only some versions are made available as executables.

1.6 Mailing Lists

There are two mailing list for the project, one for the developers and one for the users.

General user questions should be send to the users mailing list. You can find the list archive here. To join this mailing list, click here.

To report problems or submit bugs/patches, send mails to the developers mailing list. The list archive is here. Please send user questions to the users mailinglist and keep this list to development! If you want to contribute to the project, please join the mailing list.

Note: Please don't send your questions as private emails to individual developer. We are usually busy. We would not like to be your private consultant, unless you'd like to pay us. Send your problems to the appropriate public mailing list so everybody can help you.

Please also note don't send the GnuGK specific problems to the OpenH323 mailing list, or vice versa. Or you will definitely be ignored. They are different projects, though closely related. The developers are also different, though they usually work together in some ways.

Before you sending an email, make sure you have read the related documents carefully. Describe your problems clearly and precisely. Show us the error messages or logs if there is any. If you don't know how to ask questions in a public forum, read Eric S. Raymond's famous article How To Ask Questions The Smart Way before you asking.

1.7 Contributors

The current project coordinator is Jan Willamowius <jan@willamowius.de>

The main features and functions of version 2.0 are contributed by Chih-Wei Huang <cwhuang@linux.org.tw> and Citron Network Inc., including thread-safe registration and call tables, new routed mode architecture, H.323 proxy, H.235 authentication and MySQL backend.

A team at mediaWays is working on LDAP database-subsystem, overlapped sending and advanced routing mechanisms.

The initial version of the gatekeeper has been developed by Xiang Ping Chen, Joe Metzger and Rajat Todi.

2. Compiling and Installing

2.1 Compiling the Gatekeeper

To build the gatekeeper you need at least PWLib 1.2 and OpenH323 1.8 or later. The development version of the gatekeeper usually needs the most recent OpenH323 version available. These libraries are available at OpenH323 Download Page. See the instructions on how to compile the OpenH323 code.

Order of compiling:

  1. PWLib (release + debug version)
  2. OpenH323
  3. OpenH323 test application (not needed, just to make sure everything works so far)
  4. The Gatekeeper

On Unix do a make debug or make opt in the gatekeeper directory to build debug or release version, respectively. Use make both to build both versions. Note you have to use GCC 2.95.2 or later. The older version may not work.

On Windows just open and compile the provided project (gk.dsw) for Microsoft Visual C++ 6.0 or 7.0 (Visual C++ 5.0 is too old).

Since version 2.0, the Gatekeeper supports MySQL and LDAP backend databases. If you don't want MySQL support, you may set NO_MYSQL environment before making: 

$ NO_MYSQL=1 make both

To leave out LDAP support: 

$ NO_LDAP=1 make both

Or disable both with 

$ NO_MYSQL=1 NO_LDAP=1 make both

Since version 2.0.1 the Gatekeeper has implemented an extended fd_set structure that enables the Gatekeeper to support thousands of concurrent calls in routed mode. To enable this feature, export LARGE_FDSET environment variable to the maximum number of file descriptors. For example, 

$ LARGE_FDSET=16384 make opt

2.2 Installing the Gatekeeper

There is no special installation procedure needed. Just copy the executable to the directory you like and create a config file for it. There are several config examples in the etc/ subdirectory of source tree. See section Configuration File for detailed explanations.

For example, in Linux x86 platform, the optimized executable gnugk is produced in obj_linux_x86_r/ subdirectory. You may copy it to /usr/sbin/, create a config in /etc/gnugk.ini and start it by 

$ /usr/sbin/gnugk -c /etc/gnugk.ini -o /var/log/gnugk.log -ttt
See section Command Line Options for details.

2.3 Pre-Built Binaries

If you do not wish to compile the gatekeeper from source, there are several pre-built `packages' available from SourceForge. Not all versions will be made available as binaries - check what is avilable.

Red Hat packages (.rpm)

Download the RPMs and enter the following command as root, substitute in the name of the file you downloaded. 

$ rpm -Uvh gnugk-x.x.x.rpm

Debian packages (.deb)

If you are using the `stable' (woody) branch of Debian, you can install the gatekeeper by using the following command as root: 

$ apt-get install openh323gk

3. Getting Started (Tutorial)

3.1 A first simple experiment

To see that all components are up and running, get 2 Linux workstations, both connected to the LAN. Make sure you have at least version 1.1 of OpenH323 and OhPhone installed. On the first machine run the gatekeeper and ohphone (on different consoles): 

jan@machine1 > gnugk -ttt

Now the gatekeeper is running in direct mode. The "-ttt" option tells the gatekeeper to do a lot of debug output on the console (you can direct that output to a file with "-o logfile"). 

jan@machine1 > ohphone -l -a -u jan

Now this OhPhone is listening (-l) for calls and will automatically accept them (-a). It has registered as user jan with the gatekeeper that it will automatically detect. (If the auto detect fails for some reason use "-g 1.2.3.4" to specify the IP number the gatekeeper is running on.)

On the second machine run ohphone only: 

peter@machine2 > ohphone -u peter jan

The second instance of OhPhone registers with the auto detected gatekeeper as user peter and tries to call user jan. The gatekeeper will resolve the username to the IP number from where user jan has registered (machine1 in this case) and OhPhone will call the other instance of OhPhone on machine one.

The first instance of OhPhone will accept that call and Peter and Jan can chat.

3.2 Using the Status interface to spy on the gatekeeper

Now we try to see which messages are handled by the gatekeeper. On a new console on machine1 we use telnet to connect to the gatekeeper: 

jan@machine1 > telnet machine1 7000

Most probably we'll get an "Access forbidden!" message, because not everybody is allowed to spy.

Now we create a file called gatekeeper.ini and put it in the directory where we start the gatekeeper. gatekeeper.ini only contains 4 lines: 

[Gatekeeper::Main]
Fourtytwo=42
[GkStatus::Auth]
rule=allow

Stop the gatekeeper with Ctrl-C and restart it. When we do the telnet again, we stay connected with the gatekeeper. Now repeat the first experiment where Peter calls Jan and see which messages are handled by the gatekeeper in non-routed mode. There is a number of commands that can be issued in this telnet session: Type "help" to see them. To end the telnet session with the gatekeeper type "quit" and hit Enter.

3.3 Starting the gatekeeper in routed mode

Starting the gatekeeper in routed mode means that the gatekeeper uses "gatekeeper routed signalling" for all calls. In this mode the gatekeeper all signalling messages go through the gatekeeper and it has much greater control over the calls. 

jan@machine1 > gnugk -r

Now the gatekeeper is running in routed mode. Telnet to the status port and make a call to see what messages are now handled by the gatekeeper.

Note that all media packets (audio and video) are still sent directly between the endpoints (the 2 instances of ohphone).

Since gatekeeper routed signalling is much more complicated you are much more likely to hit a bug n the gatekeeper in this mode. But if it breaks, you get to keep the pieces. ;-)

3.4 A virtual PBX: Disconnecting calls

Until now the gatekeeper has only acted as a mechanism to resolve symbolic names to IP addresses. Thats an important function but hardly exciting.

Since the gatekeeper has a lot of control over the calls, it can terminate them for example. When we are connected to the status port, we can list all active calls with "PrintCurrentCalls". To terminate a call, we can say "Disconnectip 1.2.3.4" for one of its endpoints.

One could for example write a simple script that connects to the status port and listens for all ongoing calls and terminates them after 5 minutes, so no user can over use system resources.

This mechanism could also be used to call transfers between users or call forwarding. (But thats not yet implemented in the gatekeeper.)

3.5 Routing calls over a gateway to reach external users

Without using a gateway you can only call other people with an IP phone over the Internet. To reach people with ordinary telephones you must use a gateway. 

_________________          ______________
| endpoint "jan"|          |            |
| 192.168.88.35 |--------->| Gatekeeper |
|_______________|          |            |
_________________          |            |
| gateway "gw1" | outgoing |            |
| 192.168.88.37 |<---------|____________|
|_______________|

The gatekeeper has to know which calls are supposed to be routed over the gateway and what numbers shall be called directly. Use the [RasSrv::GWPrefixes] section of the config file to tell the gatekeeper the prefix of numbers that shall be routed over the gateway. 

[RasSrv::GWPrefixes]
gw1=0

This entry tells the gatekeeper to route all calls to E.164 numbers starting with 0 to the gateway that has registered with the H.323 alias "gw1". If there is no registered gateway with that alias the call will fail. (Note that you must use the gateway alias - you can't just tell the gatekeeper the IP number of the gateway.)

3.6 Rewriting E.164 numbers

When using a gateway you often have to use different numbers internally and rewrite them before sending them over a gateway into the telephone network. You can use the RasSrv::RewriteE164 section to configure that.

Example: You want to call number 12345 with you IP Phone and would like to reach number 08765 behind a gateway called "gw1". 

[RasSrv::GWPrefixes]
gw1=0

[RasSrv::RewriteE164]
12345=08765

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

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 It is said that some section names in GnuGK 2.0 are [RasSrv::*], while others are [RasSvr::*]. This inconsistency confuses users. In 2.0.1 all sections are corrected to [RasSrv::*]. If you upgrade from 2.0 or eariler version, remember to change the section names, or the 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 [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 [GkStatus::Auth]

Define a number of rules who is allowed to connect to the status port.

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.

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. Multi targets are possible. If the `!' flag precedes the original-prefix, the sense is inverted.

Example:

08=18888

If you dial 08345718, it is rewritten to 18888345718.

Option:

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.

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 its prefix match the destination or it has prefix ``*''. Currently only one prefix is supported.

Conversely, the gatekeeper only reply 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.

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

Format:

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

Example:

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

Section [RasSrv::LRQFeatures]

Defines some features of LRQ and LCF.

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 | ...
 <actions>  := <control>[;<ras>,<ras>,...]
 <control>  := optional | required | sufficient
 <ras>      := GRQ | RRQ | URQ | ARQ | BRQ | DRQ | LRQ | IRQ
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:

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

Section [Password]

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 [MySQLAuth]

Define the MySQL database, table and fileds to retrieve the userid and password.

The SQL command will be issused: 

SELECT $PasswordField FROM $Table WHERE $IDField = %id [AND $ExtraCriterion]

Section [ExternalPasswordAuth]

Specify an external program to retrieve the password. The program should accept ID from stdin and print the password to stdout.

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 [MySQLAliasAuth]

Define the MySQL database, table and fileds to retrieve a pattern for an alias.

The SQL command will be issused: 

SELECT $IPField FROM $Table WHERE $IDField = %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 [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 [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 queue to allow inbound call distribution by an external application. 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 resond with either a RouteReject (then the ARQ will be rejected) or with RouteToAlias which leads to the ARQ being rewritten so the call will be routed to the alias (eg. acll center agent) specified by the external application.

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

Right now you can have only one virtual queue per gatekeeper.

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

5. Monitoring the Gatekeeper (Reference)

5.1 Status Interface

The Status Interface is the external interface for monitoring and controlling the gatekeeper. The gatekeeper will send out messages about ongoing calls to all connected clients and it can receive commands via this interface.

The interface is a simple TCP port (default: 7000), you can connect to with telnet or another client. One example of a different client is the Java GUI, aka GkGUI.

Application Areas

What you do with the powers of the Status Interface is up to you, but here are a few ideas:

Examples

Suppose you are just interested in the CDRs (call details records) and want to process them as a batch at regular intervals.

Here is a simple Perl script (gnugk_cdr.pl) that starts the gatekeeper and also forks a very simple client for the Status Interface and writes just the CDRs into a logfile. 

#!/usr/bin/perl
# sample program that demonstrates how to write the CDRs to a log file
use strict;
use IO::Socket;
use IO::Handle;

my $logfile = "/home/jan/cdr.log";
my $gk_host = "localhost";
my $gk_port = 7000;
my $gk_pid;

if ($gk_pid = fork()) {
        # parent will listen to gatekeeper status
        sleep(1);       # wait for gk to start
        my $sock = IO::Socket::INET->new(PeerAddr => $gk_host, PeerPort => $gk_port, Proto => 'tcp');
        if (!defined $sock) {
                die "Can't connect to gatekeeper at $gk_host:$gk_port";
        }
        $SIG{HUP} = sub { kill 1, $gk_pid; };   # pass HUP to gatekeeper
        $SIG{INT} = sub { close (CDRFILE); kill 2, $gk_pid; };  # close file when terminated

        open (CDRFILE, ">>$logfile");
        CDRFILE->autoflush(1);  # don't buffer output
        while (!$sock->eof()) {
                my $msg = $sock->getline();
                $msg = (split(/;/, $msg))[0];   # remove junk at end of line
                my $msgtype = (split(/\|/, $msg))[0];
                if ($msgtype eq "CDR") {
                        print CDRFILE "$msg\n";
                }
        }
        close (CDRFILE);
} else {
        # child starts gatekeeper
        exec("gnugk");
}

GUI for the Gatekeeper

There are several Graphical User Interface (GUI) frontend for the gatekeeper.

5.2 Commands (Reference)

The command help or h will show you a list of all available commands.

5.3 Messages (Reference)

The section describes the messages output to the status interface.