Installing and configuring the GnuGK gatekeeper

From TD-er's Wiki
Revision as of 14:45, 8 March 2007 by Anneke (talk | contribs)
Jump to navigationJump to search

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

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