When setting up H.323 services, the basic component to install is a gatekeeper, in order to provide initial functionality to an installed base of H.323 clients. This basic functionality entails:
- in-zone calling among endpoints
- out-of-zone calling (incoming/outgoing)
- access to local services (e.g. gateways, multi-point conference servers)
- name resolution during calls, by H.323 alias or E.164 number
- zone management (authentication, bandwidth restriction, etc.)
In this section, we will be presenting guides for running the three most popular gatekeeper implementations that are available today. A comparison of these gatekeeper implementations based on their capabilities and requirements follows here:
Guides for basic operation of the above three gatekeepers follow, but official documentation for these products should be consulted when advanced functionality and features are required.
The Cisco MCM is a software gatekeeper that runs only on Cisco router hardware with special IOS images (H.323 feature set). One the one hand, this makes it easy to find a hardware platform for running it within most organizations that use Cisco hardware, without regard for underlying operating system support. On the other hand, it does not allow the flexibility of installing it on any available PC-based server. It is a commercial grade implementation, mostly geared towards VoIP gateway services and less towards an open H.323 community of endpoints that possibly spans organization borders. The MCM supports either direct mode dialing, or full routing mode, through the use of an included H.323 proxy server. Multiple H.323 zones can be configured and controlled on one MCM installation, but only in combination with subnet restriction rules for groups of endpoints. The MCM has good interzone routing features with DNS gatekeeper discovery as extra and performs great in a homogeneous "Cisco" environment, but has only basic support for RADIUS based authentication (by H.323 alias or E.164 and proprietary piggy-back password mechanism) and no support for LDAP H.350 authentication. "Cisco MCM VC: Configuring H.323 Gatekeepers" is available here.
Since the Cisco MCM gatekeeper is only an IOS feature (IOS being the Cisco router operating system), basic IOS installation procedures are sufficient, assuming a correct IOS image with MCM functionality has been chosen from the Cisco support site. Two tools can help you choose an appropriate IOS for your available router, but they are only available to registered users on the Cisco web site:
Look for "High-Performance Gatekeeper" under features and for "IP/H.323" under feature sets. IOS versioning is a subject difficult to follow in itself. Add to this the fact that the MCM has been undergoing changes during IOS development and gatekeeper features available on different IOS versions vary significantly, and finding the right IOS-MCM combination to use for a specific hardware configuration can become time consuming. Always prefer the latest available IOS release for your hardware, assuming enough RAM is available to accommodate it.
Working with the Cisco IOS command line interface does require some experience with basic commands, modes of operation, loading software images and configuration files, none of which procedures will be described here in detail. If you are not familiar with Cisco IOS basic commands, make sure you read an introductory guide by Cisco. To configure the Cisco MCM, you must establish command line access (telnet) to the router that runs the "IP/H.323" feature set and enter privileged (enable command) mode, indicated by the # at the prompt, before you can enter configuration commands. Enter configuration mode (config command) and then specify the "gatekeeper" section. In this section, you will need to enter the MCM configuration commands, as in the sample below, which merely initializes the gatekeeper operation:
gkp#config Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. gkp(config)#gatekeeper gkp(config-gk)#zone local gkp.mydomain.org mydomain.org gkp(config-gk)#no shutdown gkp(config-gk)#^Z
The above sample is sufficient to start gatekeeper services on the router, but a more detailed configuration with comments for a basic gatekeeper set-up follows. We have dropped the command line prompt for simplicity. The following commands can be typed at the configuration interface, as shown above. Note that all user-specified fields are indicated as enclosed in brackets and you must customize/replace them appropriately for your site.
! ! This section goes outside the gatekeeper configuration section ! as it relates to general AAA settings and RADIUS server communication. ! H.323 endpoint RAS registration will be checked against ! local IOS usernames first and then RADIUS defined usernames. ! Accounting records will be sent to RADIUS server. ! aaa new-model aaa authentication login h323 local group radius aaa accounting connection h323 start-stop group radius ! radius-server host [radius.mydomain.org] auth-port [1812] acct-port [1813] radius-server key [radius-server-key-as-defined-in-radius-host] radius-server authorization permit missing Service-Type ! ! Gatekeeper section ! gatekeeper ! ! Local zone info, as controlled by this gatekeeper ! The zone name "myzone" is for config purposes only and plays no role, ! while the domain is important for endpoints registering by e-mail alias, ! as endpoints that request to be registered by e-mail address must match ! the specified "mydomain.org" part. ! The zone prefix is important for recognizing ! in-zone calls and endpoints, e.g anything beginning with 0030234 ! zone local [myzone] [mydomain.org] zone prefix [myzone] [0030234*] ! ! To set-up connectivity with other zones and gatekeepers, ! specify the ip of the neighbouring gatekeeper with a "zone remote" ! and the prefix it services with a "zone prefix" for that zone. ! For example, if you know a neighbour gatekeeper handles ! all calls with prefix 0030248, include the following two lines. ! zone remote [neighb1] [neighb1-domain.com] [neighb1-gkp-ip] 1719 zone prefix [neighb1] [0030248*] ! ! The VideNet gatekeeper for example is the largest global network ! of H.323 zones, to which you can connect as shown below. ! Any calls beginning with 00, are routed to the VideNet gatekeeper. ! In order to accept calls from VideNet as well, ! you have to make your gatekeeper well known to the VideNet ! hierarchy of gatekeepers (see https://videnet.unc.edu/) ! zone remote videnet3 videnet 137.44.172.248 1719 zone prefix videnet3 00* lrq forward-queries add-hop-count ! ! To force endpoints to register with a specific h323-id and password ! you can use H.235 (few endpoints support it) or the h323-id/password ! mechanism that the MCM provides. ! accounting security h323-id security password separator / ! ! Make sure no H.323 proxy services are unintentionally used, ! unless proxy functionality is needed for security or QoS reasons. ! no use-proxy [myzone] default inbound-to terminal no use-proxy [myzone] default outbound-from terminal
Immediately after configuration, the MCM may service endpoints, and you can verify this by making a couple of endpoints point to the gatekeeper for registration. As soon as the endpoints register, they can be listed with the following command:
> show gatekeeper endpoints
You may proceed with calling between the two endpoints by dialling from the one the registered aliases (name or number) of the other. The ongoing call can be listed with the following command:
> show h323 gatekeeper calls
As an administrator of the gatekeeper you may disconnect the call, or even unregister an endpoint.
> clear gatekeeper call call-id . . . > unregister . . .
A view of the operational status of the gatekeeper, such as zones defined, endpoints registered, neighbour gatekeepers defined etc. may be displayed by the following command:
> show gatekeeper status
Debug logs of the gatekeeper operations may be monitored with the following sequence of commands:
> terminal monitor > debug gatekeeper main 10 > debug h225 asn1 > debug h245 asn1
The first command makes your terminal capable of displaying console style logs and debugging output. The second command produces debugging output regarding basic gatekeeper actions. Obviously, the last two commands display info on H.225 and H.245 protocols and the output can be overwhelming, but it may be the only debugging option when faced with an otherwise intractable problem. Each debugging option can be stopped by its equivalent "no debug" and all debugging output can be stopped with the "no debug all" command.
The MCM gatekeeper implements H.235 authentication, but its use is limited to gatekeeper-to-gatekeeper and gatekeeper-to-gateway authentication, because of the very limited deployment of H.235 capable endpoints. Cisco has implemented an alternative method for endpoint authentication, which allows for an H.323 or E.164 alias to carry (piggy-back) both alias info and a password, separated by an administrator defined special character, e.g. /. A configuration for this feature is provided above and once activated, endpoints must be configured to use alias/password combinations to register with the gatekeeper. There are shortcomings to this method and stem mostly from the fact that it is a proprietary solution, which in some cases exposes clear text passwords to neighbour devices (MCUs, gateways, gatekeepers). Of course, the MCM includes RADIUS support, which might allow for an IP address + alias identification method to be implemented on the RADIUS server side, but such a solution imposes restrictions to endpoint mobility.
The Cisco MCM supports RADIUS authentication and accounting to a remote RADIUS server. With the extensive support of RADIUS servers to a number of back-ends such as databases and directory services, this can be an important feature when seeking a method of integrating H.323 access control with already deployed services (e.g. dial-up, LDAP), or a simple way of storing call-accounting information in a database. Also, the exchange of standard and vendor-specific attributes during the RADIUS negotiation process allows very fine control of some delicate parameters such as "call duration" which would otherwise be inaccessible to an external-to-the-gatekeeper application. Of course, only experienced RADIUS administrators and middleware developers can exploit the full potential of the RADIUS configuration files and its back-end interfaces. The Cisco MCM supports an alternative method to neighbour discovery than static neighbour entries in the IOS configuration. A DNS-based gatekeeper discovery mechanism is in place that allows the MCM to find gatekeepers responsible for a specific domain by checking for the existence of a TXT record in the domain's DNS zone info. This can be useful if a large community of users in separate zones employs e-mail addresses for dialling. The gatekeepers serving them do not need to have static knowledge of each other, but can discover destination gatekeepers responsible for a domain through DNS. Multiple zone support is implemented on the MCM in a way that allows multiple instances of the gatekeeper to run within one router. This would have been an excellent feature, if it could have avoided a major handicap: endpoint registration to a specific gatekeeper has to be guided by administratively preset IP address subnet restrictions. Interestingly enough, Cisco gateways can utilize this functionality by indicating on their RRQ messages (by gatekeeper ID and not by IP address) which gatekeeper they request to be registered with.
The Radvision ECS is a software only gatekeeper that runs on the WinNT or Win2000 operating systems, a fact that ties it to specific remote management techniques used with all other Windows based servers. It is a commercial grade implementation and it is considered top-of-the-line for the features it provides and its compatibility even with the latest H.323 specs. It is servicing large organizations with a great number of endpoints and some of the VideNet global root gatekeepers most notably. The ECS supports all three modes of routing: direct, Q.931 routing, and both Q.931 and H.245 routing. The ECS has good interzone routing features with DNS gatekeeper discovery and neighbour gatekeeper LDAP support as extra. Authentication is very flexible, with ability for "predefined" endpoint settings enforced at registration time and LDAP H.350 support, but no RADIUS support.
"ECS gatekeeper product description" is available here.
"ECS gatekeeper specifications" are available here.
Installing the ECS gatekeeper is a very simple task, since it involves merely the execution a GUI setup wizard, which requires no configuration options. The only potential source of installation problems lies with the fact that the Windows SNMP service must be already installed, before any service packs and the ECS installer are applied. If this advice, which is listed in the ECS documentation, is ignored, the ECS installer refuses to proceed and the only option is to reinstall the operating system itself. Also, the administrator of the host must make sure that port 80 is free, since the ECS installs an HTTP service on this default port for configuration management over a web interface. The documentation also calls for an FTP server to be running at the same host, but it only serves for downloading ECS log files, which is not a required functionality.
Once installed, the ECS is ready to run with default configuration options. The administrator can access the management interface (see Figure 4.14) by launching a browser and requesting the local web server (http://localhost). The interface presents a login page, where the default username and password can be entered (admin/null-no-password). After successful login, the administrator is made aware of the fact that the management tool can supervise the operation of a whole hierarchy of ECS gatekeepers ("Global" picture), as well as the single ECS installation residing on this host ("Local" picture). Proceed with the "Local administrator" interface.
Immediately afterwards, the menus for the administration of the locally installed gatekeeper are shown, as below.
There are four commands to allow configuration management. The "Refresh" button fills in the web interface forms with configuration data from the currently running ECS gatekeeper configuration. The "Upload" button takes all the changes made on the web interface and applies them to the currently running ECS configuration. The "Import" and "Export" buttons are used to store and retrieve snapshots of the configuration at different points in time.
The rest of the interface is fairly straightforward, with an array of configuration Tabs (sections), the most important of which are listed below:
- Status Tab: allows view of the current status of the gatekeeper by indicating the number of ongoing calls and registered endpoints, as well as bandwidth usage statistics for in-zone and out-of-zone calls.
- Settings Tab: this is where most of the configuration options are specified, logically separated into a series of thematic categories (Basics, Calls, Dial Plan, Supplementary Services, Logs, LDAP, DNS, Security, Alternate Gatekeeper, Advanced).
- Endpoints Tab: allows view and control of the currently registered endpoints with details on their aliases (name and number), IP addresses and online time. This Tab can be used to "predefine" endpoints, i.e. assign specific aliases to endpoints that may later be used for endpoint identification during authentication.
- Services Tab: allows view and configuration of the currently declared services. By default, four services exist at installation time and they are not activated, since their prefix setting is null. Therefore they merely exist as templates for defining basic services functionality.
- Call Control Tab: allows view and control of the calls in progress and the setting up of gatekeeper initiated calls between arbitrary endpoints, with the "Make call" option, assuming the gatekeeper runs in fully routed mode (see Signaling Models in this book and the Settings Tab, category Calls in the ECS interface).
- Forwarding Tab: allows set-up of forwarding rules based on source and destination, for three cases: forward on busy, forward on no answer, unconditional forward.
- Hierarchy Tab: allows set-up of a parent gatekeeper in order to forward Location Requests for cases of unresolved destinations. User assigned filters may also be applied to specify and control the extent of the cases referred upstream, to the parent gatekeeper.
Even though the ECS gatekeeper runs out-of-the-box, you may want to inspect some of its basic settings and decide whether they fit the needs of your application. There are three Tabs that should be at least browsed through before proceeding with operation.
Under the Settings Tab, in the category "Basic", make a note of the name of the gatekeeper (gatekeeper ID). Also, be aware of the setting "who can register", where the choices are "everyone" for no authentication control, "predefined endpoints only" for some authentication control and "no endpoints" to turn down all endpoints for maintenance reasons only. The choice between "dial plan v.1" and "dial plan v.2" may not be obvious, but keep in mind that the second option allows more flexibility in hierarchically connected gatekeeper environments. Once chosen, it dynamically enables extra configuration sections. The option for "DHCP environment" may be used for authentication control, as it instructs the gatekeeper to identify endpoints by previously seen IP addresses and H.323 aliases (names) and authenticate them based on this information. The last choice, "merge predefined and on-line aliases upon registration" is an interesting feature, because it allows the gatekeeper to apply extra aliases to well-known and identified endpoints. E.g. an endpoint may register with a name alias only, but the gatekeeper will attach an E.164 number to this endpoint as well.
Under the Settings Tab, in the category "Calls", be aware of the "routing mode" selection, as it varies the operation of the gatekeeper dramatically. "Direct" mode employs minimal communication between endpoints and gatekeeper (RAS messages only), while "Call set-up routing" mode forces call set-up messages to be routed through the gatekeeper as well (Q.931). The third mode, forces all previous messages, as well as call control messages to be routed through the gatekeeper and not directly between the endpoints. The setting of "accept calls" can be used for maintenance reasons to turn off all calling between endpoints.
Under the Settings Tab, in the category "Dial plan", assuming you have chosen dial plan version 2, you will be able to specify stripping of zone prefixes from destination info of incoming calls. This feature may allow a more user-friendly dial plan, where in-zone endpoints use shorter dial numbers for dialling and out-of-zone endpoints use full length dial numbers.
In quick passing, check the category "Logs" if you would like to enable logging for debugging purposes and the category "Billing" to enable usage statistics and accounting. Category "DNS" will allow discovery of neighbour gatekeepers through specially crafted DNS TXT records, but it seems to be compatible only with other RADVISION gatekeepers. Category "LDAP" will allow endpoint alias data and neighbour data to be retrieved from LDAP directory services, as well as LDAP-enabled endpoint authentication.
Immediately after installation, the ECS may service endpoints, and you can verify this by making a couple of endpoints point to the gatekeeper for registration. As soon as the endpoints register, they appear at the Endpoints Tab. You may proceed with calling between the two endpoints by dialling from the one the registered aliases (name or number) of the other. The ongoing call will appear in the Call Control Tab. As an administrator of the gatekeeper you may disconnect the call, or even unregister an endpoint from the respective Tab sections. Logs of the gatekeeper operations may be started through the Settings Tab, Logs subsection and can be inspected as text files from the C:\Program Files\Radvision\ECS\Gatekeeper\Logs directory, where they are maintained and rotated, after they reach a certain size.
The ECS gatekeeper implements H.235 authentication, but its use is limited to gatekeeper-to-gatekeeper and gatekeeper-to-gateway authentication, because of the very limited deployment of H.235 capable endpoints. The ECS implements a method of storing informational data for well-known endpoints (predefined endpoints). This feature allows for an IP address + alias identification method to be implemented, but such a solution imposes restrictions to endpoint mobility.
The ECS gatekeeper is able to support hierarchies of gatekeepers (child-parent relationships) in cases where many levels of prefixes must be supported by prefix stripping or prefix substitution. For example, a country-level (parent) gatekeeper may need to know all dialed destinations by their 12-digit number, while an organization-level (child) gatekeeper may be able to operate with just 4-digit numbers most of the time. In order for the child gatekeeper to support both long and short dial strings, it needs to implement prefix stripping.
The H.450 protocol provides the implementation framework for supporting in H.323 a number of features common to conventional PBX systems. The ECS implements the H.450 protocol specifications, thus enabling many different types of forwarding: forward on busy, forward on no answer, forward on reject, etc. These features are supported only when the gatekeeper is in the full-routing mode (both call and control signal routing).
The ECS already has support for retrieving endpoint and neighbour data from LDAP, but it does so in a proprietary way. New developments in LDAP-enabled voice-over-IP services have given rise to H.350, the standardized protocol for storing and retrieving user settings and preferences regarding H.323 and SIP services. Radvision, being an active partner in the committee that developed the H.350 standard (previously known as H.LDAP or CommObject), has made the commitment to implement it in the ECS gatekeeper.
Until very recently, gatekeepers used to be single points of failure for voice-over-IP services, as endpoints in H.323 can only be registered with one gatekeeper. The ECS implements a special feature called "Alternate Gatekeeper", where two identical ECS gatekeepers on two different nodes can act in tandem, providing resilience in gatekeeper services transparently to the endpoints. This is achieved by constant exchange of information and status checking between a master and a slave gatekeeper, so that the second one can assume the role of the first in case of failure. In this case, some of the calls in progress may be disconnected, but at least redialing should be successful, without requiring the endpoints to register to a new gatekeeper.
The GNU GK is the most popular and active in development of the open-source gatekeeper projects that stem from the OpenH323 project efforts. Being an open-source effort, it benefits from availability for many different operating systems and from flexibility in configuring a multitude of features and interfaces that are not usually available in commercial products, and all these with no licensing cost. At the same time, its initial installation is made problematic by lack of quality documentation and good versioning vs. feature availability support, in contrast to a very active mailing list that users can seek help with. The GNU GK supports all three modes of routing: direct, Q.931 routing, and both Q.931 and H.245 routing. It has only basic inter-zone routing features, but authentication is very flexible, with very configurable RADIUS support and LDAP H.350 support in the works.
"OpenH323 Gatekeeper - The GNU Gatekeeper Documentation" is available here.
Installing the GNU GK gatekeeper is not a simple task, if you decide to compile the source of the gatekeeper and the two libraries it requires. However, this may be your only option, if support of MySQL and LDAP is required, since the provided precompiled binaries are lacking it. To avoid compilation of the code please refer to the Pre-Built binaries downloads at the end of this section. In order to compile and build the GNU GK you will need both the PWLib libraries (version 1.2 or later) and the OpenH323 libraries (version 1.8 or later), if you are not familiar with those libraries please refer to their web site on how to build them.
These libraries are available here. See the instructions on how to compile the code available here.
Recommended versions of the libraries are PWLib 1.4.11 or later and Openh323 1.11.7 or later. The order of compiling the packages is the following:
- PWLib (release + debug version)
- OpenH323
- OpenH323 test application (not needed, just to make sure everything works so far)
- The GNU Gatekeeper itself
To compile the GNU gatekeeper on Unix, do a "make debug" or "make opt" in the gatekeeper source directory to build debug or release versions, respectively. Use "make both" to build both versions. Note you have to use GCC 2.95.2 or later. Good practice is to do a "make debugdepend" or "make optdepend" in the gatekeeper source directory before starting actual compilation (make debug or make opt). 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).
The Gatekeeper supports MySQL and LDAP back-end interfaces (support for LDAP is still under development). The make scripts will look for the MySQL and OpenLDAP libraries in standard places, but if they are not found, you will have to explicitly point to their source directories by config options. If you do not want MySQL support, you may set the 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
For gatekeepers with a large numbers of concurrent calls, the GNU GK 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 the LARGE_FDSET environment variable to the maximum number of file descriptors. For example:
$ LARGE_FDSET=16384 make opt
The GNU GK includes implementation of a Radius protocol client that enables registration/admission authentication and authorization using Radius servers. This featured is enabled by default. To disable compilation of these Radius modules, set the NO_RADIUS environment variable before making:
$ NO_RADIUS=1 make both
The GNU GK is able to do accounting. Currently, only RADIUS and plain text file accounting modules are available. The accounting is still considered an experimental feature, so it is not compiled in by default. To enable accounting, set the HAS_ACCT environment variable before making:
$ HAS_ACCT=1 make both
Moreover, there is no special installation procedure needed. After compilation, copy the executable to a directory of your choice and create a configuration file for it. There are several configuration examples in the etc/ subdirectory of the source tree. See the next section on Configuration for further explanations.
For example, to start the gatekeeper, a command like:
$ /usr/sbin/gnugk -c /etc/gnugk.ini -o /var/log/gnugk.log -ttt
should work if the configuration file (gnugk.ini) is correct.
Pre-Built binaries - If you do not wish to compile the gatekeeper from source, there are several pre-built packages available from here. Not all versions will be made available as binaries therefore the reader will have to check what is available.
As regards the Red Hat, packages you will have to download the RPMs and enter the following command as root, substitute in the name of the file you wish downloaded.
$ rpm -Uvh gnugk-x.x.x.rpm
As regards the Debian packages, you can install the gatekeeper by using the following command as root:
$ apt-get install openh323gk
The behaviour of the gatekeeper is completely determined by the command line options at run time and the specified configuration file. Some command line options may override settings in the configuration file. In order to avoid confusion it is common practice to keep all the configuration options in the configuration file and start the GNU GK with the following command:
$ [/usr/sbin/]gnugk -c /etc/gnugk.ini -o /var/log/gnugk.log -ttt
Here we provide a sample configuration file with the most important options for setting up basic services and their relative explanation. Note that all user-specified fields are indicated as beginning with "my" and you must customize/replace them appropriately for your site.
#Two lines in order to be able to telnet your GK on a specific port #(the default is port 7000) #(the authorization rules are detailed in the [GkStatus::Auth] section) [Gatekeeper::Main] Fourtytwo=42 #name of your GK Name=my-GnuGK #Network information #Specify the network interfaces of the gatekeeper #By default the gatekeeper will detect the interfaces #of your host automatically Home=my-ip-address #information about the parent GK in order to forward LRQ #for out-of-zone calls [RasSrv::Neighbors] [neighbour-name]=my-ip-address:my-port;my-prefix-of-the-neighbour #define some features on LRQ and LCF [RasSrv::LRQFeatures] #The gatekeeper replies with LCFs containing #the destinationInfo and destinationType fields, #the registered aliases and the terminal type of the destination endpoint #The neighbor gatekeeper can then save the information #to suppress later LRQs #However, some vendors' gatekeepers misuse the information, #thus resulting in interoperability problems #set it to 0 if you encounter problems with a third-party GK IncludeDestinationInfoInLCF=0 #Include a NonStandardParameter in LRQs #to be compatible with Cisco gatekeepers CiscoGKCompatible=1 #If hopCount has reached 0, the gatekeeper shall not forward the message ForwardHopCount=10 #route mode section [RoutedMode] #Enable the gatekeeper routed mode, as opposed to the direct mode GKRouted=1 #Route the H.245 control channel, only takes effect if GKRouted=1 H245Routed=1 #Some endpoints send h245Address in the UUIE of Q.931 #even when h245Tunneling is set to TRUE #This may cause interoperability problems, avoid setting this option to 1 RemoveH245AddressOnTunneling=1 #The gatekeeper could tear down a call by sending #RAS DisengageRequest to endpoints #Some bad endpoints just ignore this command, with this option turned on, #the gatekeeper will send #Q.931 Release Complete instead of RAS DRQ to both endpoints #to force them to drop the call DropCallsByReleaseComplete=1 #Setting this parameter to 1 makes the gatekeeper #to always send Release Complete to both endpoints #before closing the call when it receives DRQ from one of the parties SendReleaseCompleteOnDRQ=1 #Authorization rules for telnet access to port #(the default is port 7000) [GkStatus::Auth] #allow only specific addresses rule=regex # - we are allowing the IP addresses 192.168.1.* regex=^(192\.168\.1\.[0-9]+) default=forbid #if you want to allow everybody, comment the previous lines and ... #rule=allow
There are a number of ways to monitor the operation of the GNU GK. A command-line (telnet) interface is provided, which is installed by default and allows monitoring of endpoints registrations and call requests. It also accepts unregistration commands for specific endpoints, call clearing and even reloading of the configuration file.
Having inserted the following lines in the configuration file:
[Gatekeeper::Main] Fourtytwo=42 [GkStatus::Auth] rule=allow
we can telnet to the GNU GK machine on the port specified in the configuration file (the default is port 7000):
me@mypc> telnet gnugk-ip-address 7000
There are a number of commands that can be issued in this telnet session: Type "help" to see a list of them. Most commands are easy and intuitive and there is no need to explain them further (for a detailed explanation see here). To end the telnet session with the gatekeeper type "quit" and hit Enter.
Moreover, there are two Graphical User Interface (GUI) front-ends for the gatekeeper in order to monitor and visualize the operations.
- Java GUI: allows you to monitor the registrations and calls that go through the gatekeeper. A right-click on a button gives you a popup menu for each endpoint. This GUI works with Java 1.0 built into most web browsers. The program is available here.
- GkGUI: A new standalone Java program. It requires Java 1.4. The GkGUI is released under GNU General Public License, available here.
The GNU Gatekeeper supports all three Radius, MySQL and LDAP backend interfaces (LDAP is still under development) for registration (RRQ) and admission (ARQ) authentication and authorization mechanisms. This is obviously a very complex as well as flexible environment in which to implement authentication and authorization methods. H.235 is supported, but more commonly ad hoc authentication methods are used, such as the IP address + alias identification method on the RADIUS server side. Special credit-time or duration restricted calling applications can be deployed on the GNU GK, assuming sufficient administrator man/hours can be spared. Please refer to [Gatekeeper::Auth] and following configuration sections on the manual web page for a more detailed configuration description of such features.
The GNU GK gatekeeper incorporates an excellent combination of the features of the Cisco MCM and the Radvision ECS, in a very flexible environment, being able to support hierarchies of gatekeepers (child-parent relationships) in cases where many levels of prefixes must be supported by prefix stripping or prefix substitution (please refer to the [Endpoint::RewriteE164] configuration section). Moreover the GNU GK implements resilience features such as "Alternate Gatekeeper" support (configuration available through the [Gatekeeper::Main] configuration section), where two identical GNU GK gatekeepers on two different nodes can act in tandem, providing resilience in gatekeeper services transparently to the endpoints. Since it is an open-source project, its value per cost ratio is very high, but the command-line interfaces it provides are not for the faint-hearted and if you do make the choice, be prepared to spend many hours over out-dated documentation and recompilations of new code-fixing releases.