Scribd
Upload
132 views3 pages

How To Read Cameleon Log Files

The Cameleon log files provide details about system operations depending on the log level set, commonly set to Regular. Errors are marked with an 'E' and important parameters on each log line are the timestamp, machine name, module, and three hexadecimal values. These values provide context about the logged event like thread ID, circuit ID, and call group or resource ID.

Uploaded by

Sudhanshu Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
132 views3 pages

How To Read Cameleon Log Files

The Cameleon log files provide details about system operations depending on the log level set, commonly set to Regular. Errors are marked with an 'E' and important parameters on each log line are the timestamp, machine name, module, and three hexadecimal values. These values provide context about the logged event like thread ID, circuit ID, and call group or resource ID.

Uploaded by

Sudhanshu Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

How to read Cameleon log files.

The log files of Cameleon are showing details depending on the log level set. Commonly the log level is set to
Regular. In case of problems it might be set to Verbose or Debug.

General information:

It is important that the system time is accurate. Kindly do check that regularly or use NTP to synchronize the
system date/time with a Network Time server.

Errors occurring in all log files have category ‘ E ‘. Therefore it is advised to start a search on all logs for a line
containing the string ‘ E ‘ (<space>E<space>). Same accounts for keywords like: error and failure.

An easy way to ‘filter’ logs on keywords or resource values is to use the windows “find” command or Linux
‘grep’ command.

Examples:

C:\ find “ E “ mcnms-1.log > output.txt


C:\ find “00010004” mcunms1-log > Resource_00010004.txt

Log extract from the MCU/MCS and App:

64895.765-08-18:01:35.765 V reliance mITF 00002228 00010002 ffffffff Declare Resource CG6565 Id 0.Trunk-1.ch-002. Type=0x1.Caps=0x7C3F

53516.453-03-14:51:56.453 N one97-68 sGRP 00003280 00047809 020001e2 Reset Group

19:20:26.772 R til123 DBMS 00000b4c ffffffff 00000005 Proc 5 DBMS_Detach( 0x2972 ) , dbms_result=0

The important parameters on each line are the timestamp, the machine name, the module that is logging and
the three hexadecimal parameters.

In the above example:

Timestamp: 18:01:35.265
Character: Category (see manual for details)
String1: Machine name
String2: Interface module description (see manual for details)
Hex value 1 : 0x00002228
Hex value 2: 0x00010002
Hex value 3: 0xffffffff
Explanation hex value 1:
This is the thread Id of the thread that runs and displays the logging message.

Explanation hex value 2:


This value is context dependent. It can mean:

 Call reference number (For call related operations in MCS)


 Circuit identification for some operations in MCU (composed with Board number, Trunk number and
Circuit number)
 Generally 0xFFFFFF in application, but used for APPID on event related messages

Circuit Identification number.


The circuit identification number is a hexadecimal value which represents the physical resource used:

 First two digits: board number (starts from 0)


 Second two digits: trunk number (starts from 0)
 Last four digits: channel number (starts from 1)

Value 0x00000001 represents board 0, trunk 0 and channel 1. Value 0x00010002 represents board 0,
trunk 1, and channel 2.

Explanation hex value 3:


This value is also context dependent. It can mean:

 Call Group ID for call related functions, Resource ID for Resource related functions, Client (MCU/APP)
connection ID in MCS
 Resource ID for operations in MCU
 Generally 0xFFFFFF in application log, but used for AEP ID on event related messages

Explanation of ID’s:
 0x02xxxxxx identifies a Group context ID
 0x04xxxxxx identifies a Resource/Device ID
 0x08xxxxxx identifies a Client connection ID
 0x4xxxxxxx identifies a communication message/events
Tracing of incoming calls:

The call is landed on the MCU (this can be found using calling/called party number and the time) and passed to
the MCS.

The MCS receive the call notification, and creates a Call Group ID and a unique Reference Number. These two
are sent to the application that is selected as the target for the call (based on routing rules).

At the application log the call is received and processed.

Tracing of outgoing calls:

The outbound application initiates a call which is sent to the MCS. (This can be checked easily by using the
timestamp and the Calling/called party number.)

The MCS will allocate a Call Group ID and a unique Reference Number which are sent back to the application.
Next the MCS will select a device from the pool which is passed as a parameter on the makecall instruction,
taking in consideration the pool properties (round robin/first fit etc.)

Now we have a Device ID associated to the Call Group ID and the Reference number.

When working with SS7 and SIP the call control and media control is separated. This will result in a ResSignal
ID for Call Control and a ResTrunk ID for the media circuit.
These Resource/Device IDs will be shown in the MCU when processing the call.

Using the Circuit identification number when can determine which board/trunk/channel was performing the
outbound call.

- End of Document.

You might also like