Installing and configuring the GnuGK gatekeeper
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.
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).
GnuGK from the command line
Start the gatekeeper with the following command:
gnugk -ttt -rr
-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).