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.
Almost every option has a short and a long format, e.g.,
-c
is the same as --config
.
-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 number) 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.
-u --user name
Run the gatekeeper process as this user. Only valid for Unix versions.
--core n
(Unix only) Enable writting core dump files when the application crashes. A core dump file will not exceed n bytes in size. A special constant "unlimited" may be used to not enforce any particular limit.
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.
-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.
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`
Fourtytwo=42
N/A
This setting is used to test the presence of the config file. If it is not found, a warning is issued. Make sure it's in all your config files.
Name=OpenH323GK
OpenH323GK
Gatekeeper identifier of this gatekeeper. The gatekeeper will only respond to GRQs for this ID and will use it in a number of messages to its endpoints.
Home=192.168.1.1
0.0.0.0
The gatekeeper will listen for requests on this IP number. By default, the gatekeeper listens on all interfaces of your host. You should leave out this option, unless you want the gatekeeper only to bind to a specified IP. Multiple Home addresses can be used and have to be separated with a semicolon (;) or comma (,).
NetworkInterfaces=192.168.1.1/24,10.0.0.1/0
N/A
Specify the network interfaces of the gatekeeper. By default the gatekeeper will detect the interfaces of your host automatically. There are two situations that you may want to use this option. One is automatical detection failed, another is the gatekeeper is behind an NAT box and allow endpoints with public IPs to register with. In this case you should set the option just as the gatekeeper is running on the NAT box.
EndpointIDSuffix=_gk1
_endp
The gatekeeper will assign a unique identifier to each registered endpoint. This option can be used to specify a suffix to append to the endpoint identifier. This is only usefull when using more than one gatekeeper.
TimeToLive=300
-1
An endpoint's registration with a gatekeeper may have a limited life span. The gatekeeper specifies the registration duration of an endpoint by including a timeToLive field in the RCF message. After the specified time, the registration has expired. The endpoint shall periodically send an RRQ having the keepAlive bit set prior to the expiration time. Such a message may include a minimum amount of information as described in H.225.0. This is called a lightweight RRQ.
This configuration setting specifies the time-to-live timer in seconds until the registration expires. Note the endpoint may request a shorter timeToLive in the RRQ message to the gatekeeper. To avoid an overload of RRQ messages, the gatekeeper automatically adjusts this timer to 60 seconds if you give a lesser value!
After the expiration time, the gatekeeper will subsequently send two IRQ messages to query if the endpoint is still alive. If the endpoint responds with an IRR, the registration will be extended. Otherwise the gatekeeper will send a URQ with reason ttlExpired to the endpoint. The endpoint must then re-register with the gatekeeper using a full RRQ message.
To disable this feature, set it to -1
.
TotalBandwidth=100000
-1
Total bandwidth available to be given to endpoints. By default this feature is off. Be carefull when using it, because many endpoints have buggy implementations.
RedirectGK=Endpoints > 100 || Calls > 50
N/A
This option allow you to redirect endpoints to alternate gatekeepers when the gatekeeper overloaded. For example, with the above setting the gatekeeper will reject an RRQ if registered endpoints exceed 100, or reject an ARQ if concurrent calls exceed 50.
Furthermore, you may explicitly redirect all endpoints by
setting this option to temporary
or permanent
.
The gatekeeper will return an RAS rejection message with a list of
alternate gatekeepers defined in AlternateGKs
.
Note that a permanent
redirection means that the redirected endpoints
will not register with this gatekeeper again.
Please also note the function only takes effect to H.323 version 4
compliant endpoints.
AlternateGKs=1.2.3.4:1719:false:120:OpenH323GK
N/A
We allow for existence of another gatekeeper to provide redundancy. This is implemented in a active-active manner. Actually, you might get into a (valid !) situation where some endpoints are registered with the first and some are registered with the second gatekeeper. You should even be able use the two gatekeepers in a round_robin fashion for load-sharing (that's untested, though :-)). If you read on, "primary GK" refers to the gatekeeper you're currently configuring and "alternate GK" means the other one. The primary GK includes a field in the RCF to tell endpoints which alternate IP and gatekeeper identifier to use. But the alternate GK needs to know about every registration with the primary GK or else it would reject calls. Therefore our gatekeeper can forward every RRQ to an alternate IP address.
The AlternateGKs config option specifies the fields contained in the primary GK's RCF. The first and second fields of this string define where (IP, port) to forward to. The third tells endpoints whether they need to register with the alternate GK before placing calls. They usually don't because we forward their RRQs, so they get registered with the alternate GK, too. The fourth field specified the priority for this GK. Lower is better, usually the primary GK is considered to have priority 1. The last field specifies the alternate gatekeeper's identifier.
SendTo=1.2.3.4:1719
N/A
Although this information is contained in AlternateGKs, you must still specify which address to forward RRQs to. This might differ from AlternateGK's address, so it's a separate config option (think of multihomed machines).
SkipForwards=1.2.3.4,5.6.7.8
N/A
To avoid circular forwarding, you shouldn't forward RRQs you get from the other GK (this statement is true for both, primary and alternate GK). Two mechanisms are used to identify whether a request should be forwarded. The first one looks for a flag in RRQ. Since few endpoints implement this, we need a second, more reliable way. Specify the other gatekeeper's IP in this list.
StatusPort=7000
7000
Status port to monitor the gatekeeper. See this section for details.
SignalCallId=1
0
Signal call IDs in ACF/ARJ/DCF/DRJ/RouteRequest messages on the status port. See this section for details.
StatusTraceLevel=2
2
Default output trace level for new status interface clients. See this section for details.
TimestampFormat=ISO8601
Cisco
Control default format of timestamp strings generated by the gatekeeper.
This option affects
[SqlAcct],
[RadAcct],
[FileAcct]
and other modules, except
[CallTable].
You can further customize timestamp formatting per-module by configuring
per-module TimestampFormat
setting.
There are four predefined formats:
RFC822
- a default format used by the gatekeeper (example: Wed, 10 Nov 2004 16:02:01 +0100)ISO8601
- standard ISO format (example: 2004-11-10 T 16:02:01 +0100)Cisco
- format used by Cisco equipment (example: 16:02:01.534 CET Wed Nov 10 2004)MySQL
- simple format that MySQL can understand (example: 2004-11-10 16:02:01)If you need another format, you can build your own format string, using
rules known from strftime
C function (see man strftime or search MSDN for strftime).
In general, the format string consists of regular character and format codes, preceeded
by a percent sign. Example: "%Y-%m-%d and percent %%" will result in "2004-11-10 and percent %".
Some common format codes:
%a
- abbreviated weekday name%A
- full weekday name%b
- abbreviated month name%B
- full month name%d
- day of month as decimal number%H
- hour in 24-hour format%I
- hour in 12-hour format%m
- month as decimal number%M
- minute as decimal number%S
- second as decimal number%y
- year without century%Y
- year with century%u
- microseconds as decimal number (this is a GnuGk extension)%z
- time zone abbreviation (+0100)%Z
- time zone name%%
- percent signEncryptAllPasswords=1
0
Enable encryption of all passwords in the config (SQL passwords, RADIUS
passwords, [Password] passwords, [GkStatus::Auth] passwords). If enabled,
all passwords have to be encrypted using addpasswd
utility. Otherwise
only [Password] and [GkStatus::Auth] passwords are encrypted (old behaviour).
KeyFilled=0
N/A
Define a global padding byte to be used during password encryption/decryption.
It can be overriden by setting KeyFilled
inside a particular config section.
Usually, you do not need to change this option.
Most users will never need to change any of the following values. They are mainly used for testing or very sophisticated applications.
UseBroadcastListener=0
1
Defines whether to listen to broadcast RAS requests. This requires binding to all interfaces on a machine so if you want to run multiple instances of gatekeepers on the same machine you should turn this off.
UnicastRasPort=1719
1719
The RAS channel TSAP identifier for unicast.
MulticastPort=1718
1718
The RAS channel TSAP identifier for multicast.
MulticastGroup=224.0.1.41
224.0.1.41
The multicast group for the RAS channel.
EndpointSignalPort=1720
1720
Default port for call signalling channel of endpoints.
ListenQueueLength=1024
1024
Queue length for incoming TCP connection.
SignalReadTimeout=1000
1000
Time in miliseconds for read timeout on call signalling channels (Q931).
StatusReadTimeout=3000
3000
Time in miliseconds for read timeout on status channel.
StatusWriteTimeout=5000
5000
Time in miliseconds for write timeout on status channel.
Define a number of rules who is allowed to connect to the status port. Whoever has access to the status port has full control over your gatekeeper. Make sure this is set correctly.
rule=allow
forbid
Possible values are
forbid
- disallow any connection.allow
- allow any connectionexplicit
- reads the parameter ip=value
where ip
is the IP address of the peering client,
value
is 1,0
or allow,forbid
or yes,no
.
If ip
is not listed the parameter default
is used.regex
- the IP of the client is matched against the given regular expression.
To allow client from 195.71.129.0/24 and 195.71.131.0/24:
regex=^195\.71\.(129|131)\.[0-9]+$
password
- the user has to input appropriate username and password to login. The format of username/password is the same as
[SimplePasswordAuth] section.
Moreover, these rules can be combined by "|" or "&". For example,
rule=explicit | regex
explicit
or regex
rule.
rule=regex & password
regex
rule, and the user has to login by username and password.default=allow
forbid
Only used when rule=explicit
.
Shutdown=forbid
allow
Whether to allow shutdown the gatekeeper via status port.
DelayReject=5
0
How long (in seconds) to wait before rejecting invalid username/password for the status line access.
This section defines log file related parameters. Currently it allows users to specify log file rotation options.
Rotate=Hourly | Daily | Weekly | Monthly
N/A
If set, the log file will be rotated based on this setting. Hourly rotation
enables rotation once per hour, daily - once per day, weekly - once per week
and monthly - once per month. An exact rotation moment is determined by a combination
of RotateDay
and RotateTime
variables. During rotation, an existing
file is renamed to CURRENT_FILENAME.YYYYMMDD-HHMMSS, where YYYYMMDD-HHMMSS
is replaced with the current timestamp, and new lines are logged to an empty
file. To disable the rotation, do not set Rotate
parameter or set it to 0.
[LogFile]
Rotate=Hourly
RotateTime=45
[LogFile]
Rotate=Daily
RotateTime=23:00
[LogFile]
Rotate=Weekly
RotateDay=Sun
RotateTime=00:59
[LogFile]
Rotate=Monthly
RotateDay=31
RotateTime=23:00
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.
The gatekeeper doesn't route them. The H.245 control channel and logical channels are established directly between the endpoints.
The H.245 control channel is routed between the endpoints through the gatekeeper, while the logical channels are established directly between the endpoints.
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.
GKRouted=1
0
Whether to enable the gatekeeper routed signaling mode.
H245Routed=1
0
Whether to route the H.245 control channel through the gatekeeper too.
Only takes effect if GKRouted=1
and H.245 tunneling is disabled
for a call. Even when this option is disabled, if Proxy or ProxyForNAT
takes effect, an H.245 channel is always routed through the gatekeeper
for calls being proxied.
CallSignalPort=0
1721
The port of call signalling for the gatekeeper.
The default port is 1721
. We don't use the well-known port 1720
so you can run an H.323 endpoint in the same machine of the gatekeeper.
You may set it to 0
to let the gatekeeper choose an arbitrary port.
CallSignalHandlerNumber=2
1
The number of threads dedicated to handle signaling/H.245 channels. You may increase this number in a heavy loaded gatekeeper. Each thread can process one signaling message at time, so increasing this number will increase call throughput. Under Windows, there exists a default limit of 64 sockets used by a single signaling thread, so each signaling thread is able to handle at most 32 calls (with H.245 tunneling enabled).
RtpHandlerNumber=2
1
The number of RTP proxy handling threads. Increase this value only if you experience problems with RTP delay or jitter on a heavily loaded gatekeeper. A special care has to be taken on Windows, at RTP handling threads are subject of the same limit of 64 sockets as signalling threads. Each RTP thread is able to handle at most 32 proxied calls (2 sockets per call).
AcceptNeighborsCalls=1
1
With this feature enabled, the call signalling thread will accept calls without a pre-existing CallRec found in the CallTable, provided an endpoint corresponding to the destinationAddress in Setup can be found in the RegistrationTable, and the calling party is its neighbors or parent GK. The gatekeeper will also use it's own call signalling address in LCF in responding to an LRQ. That means, the call signalling will be routed to GK2 in GK-GK calls. As a result, the CDRs in GK2 can correctly show the connected time, instead of 'unconnected'.
AcceptUnregisteredCalls=1
0
With this feature enabled, the gatekeeper will accept calls from any unregistered endpoint. However, it raises security risks. Be careful to use it.
RemoveH245AddressOnTunneling=1
0
Some endpoints send h245Address in the UUIE of Q.931 even when h245Tunneling is set to TRUE. This may cause interoperability problems. If the option is TRUE, the gatekeeper will remove h245Address when h245Tunneling flag is TRUE. This enforces the remote party to stay in tunnelling mode.
RemoveCallOnDRQ=0
1
With this option turning off, the gatekeeper will not disconnect a call if it receives a DRQ for it. This avoids potential race conditions when a DRQ overtakes a Release Complete. This is only meaningful in routed mode because in direct mode, the only mechanism to signal end-of-call is a DRQ.
DropCallsByReleaseComplete=1
0
According to Recommendation H.323, the gatekeeper could tear down a call by sending RAS DisengageRequest to endpoints. However, some bad endpoints just ignore this command. With this option turning on, the gatekeeper will send Q.931 Release Complete instead of RAS DRQ to both endpoints to force them drop the call.
SendReleaseCompleteOnDRQ=1
0
On hangup, the endpoint sends both Release Complete within H.225/Q.931 and
DRQ within RAS. It may happen that DRQ is processed first, causing the
gatekeeper to close the call signalling channel, thus preventing the
Release Complete from being forwarding to the other endpoint.
Though the gatekeeper closes the TCP channel to the destination,
some endpoints (e.g. Cisco CallManager) don't drop the call even if
the call signalling channel is closed.
This results in phones that keep ringing if the caller hangs up
before the callee pickups.
Setting this parameter to 1
makes the gatekeeper always send
Release Complete to both endpoints before closing the call when
it receives DRQ from one of the parties.
SupportNATedEndpoints=1
0
Whether to allow an endpoint behind an NAT box register to the gatekeeper. If yes, the gatekeeper will translate the IP address in Q.931 and H.245 channel into the IP of NAT box.
Since 2.0.2, the GnuGk supports NAT outbound calls (from an endpoint behind NAT to public networks) directly without any necessary modification of endpoints or NAT box. Just register the endpoint with the GnuGk and you can make call now.
ScreenDisplayIE=MyID
N/A
Modify the DisplayIE of Q.931 to the specified value.
ScreenCallingPartyNumberIE=0965123456
N/A
Modify the CallingPartyNumberIE of Q.931 to the specified value.
ScreenSourceAddress=MyID
N/A
Modify the sourceAddress field of UUIE element from Q.931 Setup message.
ForwardOnFacility=1
0
If yes, on receiving Q.931 Facility with reason callForwarded, the gatekeeper will forwards call Setup directly to the forwarded endpoint, instead of passing the message back to the caller. If you have broken endpoints that can't handle Q.931 Facility with reason callForwarded, turn on this option. Note that this feature may not always work correctly, as it does not provide any means of capability renegotiation and media channel reopening.
ShowForwarderNumber=0
0
Whether to rewrite the calling party number to the number of forwarder.
It's usually used for billing purpose.
Only valid if ForwardOnFacility=1
.
Q931PortRange=20000-20999
N/A (let the OS allocate ports)
Specify the range of TCP port number for Q.931 signalling channels.
Note the range size may limit the number of concurrent calls.
Make sure this range is wide enough to take into account TIME_WAIT
TCP socket timeout before a socket can be reused after closed.
TIME_WAIT may vary from 15 seconds to a few minutes, depending on an OS.
So if your range is 2000-2001 and you made two calls, next two can be
made after TIME_WAIT timeout elapses and the sockets can be reused.
The same applies to H245PortRange
and T120PortRange
. TIME_WAIT
can be usualy tuned down on most OSes.
H245PortRange=30000-30999
N/A (let the OS allocate ports)
Specify the range of TCP port number for H.245 control channels.
Note the range size may limit the number of concurrent calls.
See remarks about TIME_WAIT socket state timeout in the Q931PortRange
description.
SetupTimeout=4000
8000
A timeout value (in milliseconds) to wait for a first message (Setup) to be received after a signaling TCP channel has been opended.
SignalTimeout=10000
15000
A timeout value (in milliseconds) to wait for a signalling channel to be opened after an ACF message is sent or to wait for an Alerting message after a signalling channel has been opened. This option can be thought as a maximum allowed PDD (Post Dial Delay) value.
AlertingTimeout=60000
180000
A timeout value (in milliseconds) to wait for a Connect message after a call entered Alerting state. This option can be thought as a maximum "ringing time".
TcpKeepAlive=0
1
Enable/disable keepalive feature on TCP signaling sockets. This can help to detect inactive signaling channels and prevent dead calls from hanging in the call table. For this option to work, you also need to tweak system settings to adjust keep alive timeout. See docs/keepalive.txt for more details.
TranslateFacility=1
0
Enable this option if you have interoperability problems between H.323v4 and non-H.323v4 endpoints. It converts Facility messages with reason = transportedInformation into Facility messages with an empty body, because some endpoints do not process tunneled H.245 messages inside Facility, if the body is not empty. The conversion is performed only when neccessary - if both endpoints are v4 or both endpoints are pre-v4, nothing is changed.
SocketCleanupTimeout=1000
5000
Define time to wait before an unused socket is closed (if it is not yet closed) and deleted (its memory is released). If you use very small port ranges, like a few ports (e.g. RTPPortRange=2000-2009), you may want to decrease this value to get sockets reusable faster.
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.
Enable=1
0
Whether to enable the proxy function. You have to enable gatekeeper routed mode first (see the previous section). You don't have to specify H.245 routed. It will automatically be used if required.
InternalNetwork=10.0.1.0/24
N/A
Define the networks behind the proxy. Multiple internal networks are allow. The proxy route channels only of the communications between one endpoint in the internal network and one external. If you don't specify it, all calls will be proxied.
InternalNetwork=network address/netmask[,network address/netmask,...]
The netmask can be expressed in decimal dot notation or CIDR notation (prefix length), as shown in the example.
InternalNetwork=10.0.0.0/255.0.0.0,192.168.0.0/24
T120PortRange=40000-40999
N/A (let the OS allocate ports)
Specify the range of TCP port number for T.120 data channels.
Note the range size may limit the number of concurrent calls.
See remarks about TIME_WAIT socket state timeout in the Q931PortRange
description.
RTPPortRange=50000-59999
1024-65535
Specify the range of UDP port number for RTP/RTCP channels. Note the range size may limit the number of concurrent calls.
ProxyForNAT=1
1
If yes, the gatekeeper will proxy for calls to which one of the endpoints participated is behind an NAT box. This ensure the RTP/RTCP stream can penetrate into the NAT box without modifying it. However, the endpoint behind the NAT box must use the same port to send and receive RTP/RTCP stream. If you have bad or broken endpoints that don't satisfy the precondition, you have better to disable this feature and let the NAT box forward RTP/RTCP stream for you.
ProxyForSameNAT=0
0
Whether to proxy for calls between endpoints from the same NAT box. You do not need to enable this feature in general, since usually endpoints from the same NAT box can communicate with each other.