Author’s note: This article supports our legacy products. At Inventive Labs, after two decades of providing telephony tools, we never stop supporting those who rely on our products to run their businesses. We no longer recommend Dialogic. This article is for our customers who are using legacy equipment. For more information about these legacy products and where we are today, read Ditch Dialogic & Convert to Voice Elements.
CTI32 has detailed logging at both the CTI32Engine level and the CTI32 level. Both of these logs can be accessed from the CTI32Config application.
However, Dialogic has its own internal logging. These logs can be found in the \Program Files\Dialogic\HMP\log folder.
By default these logs are set to a minimum logging level. In their default mode, they only log severe exceptions.
Sometimes, it is necessary to increase the logging to a level that will allow you diagnose problems that are otherwise difficult to resolve.
Be forewarned, by changing the log settings, the logs can become very large, and somewhat intimidating. But at the same time they can provide extremely useful information in isolating configuration issues, as well as reporting bugs to Dialogic.
Where to Modify the Settings
Although the logs are stored in the \log folder, the file that controls the logging is located in \Program Files\Dialogic\HMP\cfg in a file called RtfConfigWin.xml
You will need a text editor to modify this file.
We also recommend that you save a copy of this file before you modify it so that you can easily restore it if necessary.
Modifying The Log File Count and Size
The first thing you need to do is give the log files some room.
Find the line in the file that appears as so:
<Logfile duplicate_to_debug_console="0" log_format="text" maxbackups="10" path="$(INTEL_DIALOGIC_DIR)\log" preserve_maxbackups="10" preserve_size="3000" size="3000"/>
You’ll want to change the line to the following:
<Logfile duplicate_to_debug_console="0" log_format="text" maxbackups="10" path="$(INTEL_DIALOGIC_DIR)\log" preserve_maxbackups="10" preserve_size="10000" size="10000"/>
This change allows you to keep larger files (10MB) instead of (3MB). You can optionally change the maxbackups and preserve_maxbackups to change the number of files the folder will keep before deleting the older log files.
Understanding the Format
In the file, you will find sections that look like the following:
-- Global Call -- -- LIBGC -- <Module family="DM3,SPWR,HMP" name="gc" state="1" technology="PSTN"> <MLabel name="INTF" state="0"/> <MLabel name="DEBG" state="0"/> <MLabel name="INFO" state="0"/> <MLabel name="WARN" state="0"/> <MLabel name="APPL" state="0"/> <MLabel name="EXCE" state="1"/> <MLabel name="ERR1" state="1"/> </Module>
This section pertains to the Global Call library. Specifically the DM3, Springware, and HMP utilizations of the global call protocol. By enabling logging for this library you would get information on global call events, global call entry points, etc.
You can enable logging messages for various types (DEBG, INFO, WARN, etc).
Usually we recommend that you enable all types for a library if you need that section at all.
To enable logging for that section set all of the state to a value of 1.
<MLabel name="INTF" state="1"/>
Deciding on What Logs to Enable
This can get tricky. If you enable everything, you will get huge log files and you may miss an important message in a sea of other messages. We usually recommend modules for specific circumstances.
For example, GC is for global call and should only be enabled if you are using global call and are interested in when calls are placed or answered and the nuances involved in setting up and tearing down calls.
Here are some common libraries that may be of some use:
GC - Global Call Dm3Fax - Faxing via HMP or DM3 boards Dm3low - DTMF, and Low Level processes involved in HMP or DM3
Implementing Your Changes
Some changes become recognized by the logging subsystem as soon as you save the file. Others do not. To ensure a complete update of all the modules, you would need to restart your computer. But most of the time you can simply tell the logging system to restart.
On newer versions of HMP (> SU 182) do the following:
rtftool clean rtftool reload
On older versions of HMP, this was the appropriate way to reset the logs:
This can only be done from a console session, not a Remote Desktop session. (If you use RDP to log-in to the console, that will work as well.) Open a command prompt and type:
This should reset the logging and begin your new logging scheme.