Installing and configuring the GnuGK gatekeeper

Installing GnuGK

Packages for the GnuGK gatekeeper are not present in the CentOS package repositories.

For testing purposes we first installed GnuGK on a Debian Linux machine; this is rather straight ahead:

as root user you execute

apt-get install gnugk

Now the GnuGK is present, an can be started either through a init.d script or from the command line.

Once the usefulness of GnuGK has been proven, of course it is practical to run the gatekeeper on the TrixBox. Unluckily there is no CentOS-package for it, so we first need to add other repositories.

It turns out that OpenSUSE delivers GnuGK as a package, so we will add those repositories to the yum package manager:

[root@asterisk1 ~]# cd /etc/yum.repos.d/
[root@asterisk1 yum.repos.d]# wget http://www.personal.uni-jena.de/~p1woro/suse-yum/suse-base.repo

the added file looks as follows:

[base]
name=Suse Linux - Base Repository
#baseurl=http://download.opensuse.org/distribution/SL-$releasever/inst-source/suse
mirrorlist=http://www.personal.uni-jena.de/~p1woro/suse-yum/suse-base.mirrors
enabled=1
gpgcheck=1
gpgkey=http://download.opensuse.org/distribution/SL-$releasever/inst-source/pubring.gpg

In order not to generate confusion we change the name between square brackets and we add a protected parameter to integrate the repositories with the ones from CentOS. We also need to substitute the variable $releasever with the hardcocded value 10.1, as the CentOS release version numbering is different from the one of OpenSUSE.

The file then looks as follows:

[suse-base]
name=Suse Linux - Base Repository
baseurl=http://download.opensuse.org/distribution/SL-10.1/inst-source/suse
#mirrorlist=http://www.personal.uni-jena.de/~p1woro/suse-yum/suse-base.mirrors
enabled=1
gpgcheck=1
gpgkey=http://download.opensuse.org/distribution/SL-10.1/inst-source/pubring.gpg
protected=0

The standard yum and rpm package managers do not seem to cope adequately with the added large repository, so we update them. This goes as follows:

[root@asterisk1 yum.repos.d]# yum install rpm

this upgrades rpm to version XXX. Next, we update the yum package manager.

previous text

Packages for this gatekeeper are not available for CentOS. We found out that this gatekeeper was already installed in Etch. (System administration provided us with two machines with etch so we could get the sound working).

Running GnuGK

GnuGK from the command line

Start the gatekeeper with the following command:

gnugk -ttt -rr

Options:

-d --direct

    Use direct endpoint call signaling. 
-r --routed

    Use gatekeeper routed call signaling. 
-rr --h245routed

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

The "-ttt" option tells the gatekeeper to do a lot of debug output 

It seems of the utmost importance that you use the -rr instead of the -r option. This made all the difference in trying to establish a SIP -> H323 call.

Once the gatekeeper is installed you can register your gnomemeeting clients and the trixbox with the gatekeeper. For the trixbox this means an amportal restart. For the clients you need to open the preferences and register with the gatekeeper. For all practical purposes it is wisest to always start your gatekeeper first before starting any other applications. That way all devices can register once started.

How can the gatekeeper handle calls:

From Gnugk website:

Call signaling messages may be passed in two ways. The first method is Direct Endpoint Call Signaling, in which case the call signaling messages are passed directly between the endpoints. The second method is Gatekeeper Routed Call Signaling. In this method, the call signaling 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 signaling 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.

To make H323 -> SIP calls we are interested in Case III. We haven't accomplished anything in this area (yet).