| CONTACT | DEVELOPER CENTER | PARTNERS | SITEMAP

GO

Dialogic Support Helpweb

Dialogic® Signaling and SS7 Products

Quick Guide to Dialogic® Signaling Software SS7 gctload Messages

Summary:
This document provides a starting point for understanding the screen output that is generated by Dialogic® Signaling Software gctload messages.

Description:
When using Dialogic® Signaling Boards, the gctload command reads the config files, starts the protocol modules, and then remains there running and sending messages to the screen, e.g.:

S7L:I0000 M t02ef i003f fd2 dc2 s01 p010000000000000000

These messages can also be optionally sent to a logfile for error reporting.

One issue is how to decode these messages. Each line signifies a message that has been sent from one protocol module to another, so the lines can be used to conclude if the system is working correctly.

Example 1

S7L:I0000 M t02ef i003f fd2 dc2 s01 p010000000000000000

The 't' field is the identity of the message, in this case 0x2ef. The 'f' field indicates which module sent the message, in this case 0xd2, which is M3UA. The 'd' field indicates the recipient 0xc2, which is mbm, i.e., the management task. Finally 'p' is the parameter field that carries message-specific information.

From all this we can tell that M3UA sent a message to mbm, and the message type was 0x2EF. Knowing it is M3UA that sent the message, we can consult the M3UA Programmer's Guide (U02STN02-M3UA-PM.pdf), where, on page 103, we see that this is M3U_MSG_M3U_ERROR, "which signals an internal error warning to management."

The 's' field gives us a status return code, which should be zero for success. Here it is 1, which provides a clue that something is not right.

Looking at the parameter area of the message, we can decode the 'p' field too:

p010000000000000000

  offset 0, 1 byte, [01 in our case], instance 1
  offset 1, 4 bytes [00 00 00 00], err_val1 = 0
  offset 5, 4 bytes [00 00 00 00], err_val2 = 0

So in this example, M3UA has hit an internal error; one would report this error to Dialogic Technical Support for further assistance.

Example2
This example is from a MTU/MTR demo (sending an SMS from an application):

S7L:I0000 T 00000000 M t87e3 i0000 f15 d2d s00 p820501000b0906070400000100190201

This is a message from MAP (f = 0x15) and is directed towards 0x2d ( d = 0x2d ), which is a user application. By convention, the module ID of applications always ends in "d", so 0x2d, 0x3d are among those commonly seen. We know it is MAP, so we use the MAP Programmer's Manual (U14SSS09-MAP-PM.pdf), and look for message type 0x87e3 (t = 87e3). There, we find that this is MAP_MSG_DLG_IND, "Protocol message sent from MAP to the MAP-User containing a MAP dialogue primitive."

The 's00' tells us that the message status was 00, or successful.

Once again we can decode the parameter field:

p820501000b0906070400000100190201

  offset 0, 1 byte, [82 in our case], Dialogue primitive type octet, MAPDT_OPEN_CNF
  offset 1,            [05 01 00]         name = 5, length = 1, data = 0  (parameter 1)
  offset 4,            [0b 09 06 07 04 00 00 01 00 19 02]    name = 12, length = 9, data = 06 07 ...
  offset 15,          [01 00], end 

In this case there is a dialogue primitive type octet (0x82 or 130, meaning MAPDT_OPEN_CNF) with two parameters packed after it.  In this case 5 = MAPPN_result, and 0xB (=11) = MAPPN_applic_context, which are also described in the same MAP Programmer's Guide:

MAPPN_result (05), length 01, data=00  (0 = dialogue was accepted)
MAPPN_applic_context (11), length 09, data = 06 07 04 00 00 01 00 19 02, a Q.773 object identifier tag

Module IDs
Where can one look up the module IDs that are used in the messages?  The definitive place is in the SYSTEM.TXT configuration file, which lists the ones in use with LOCAL statements:

LOCAL 0x14 * TCAP
LOCAL 0x15 * MAP

The modules can actually be loaded using any available module ID, which can be useful if for example you wanted to run two different instances of MAP on the same server.  Generally however, they follow conventions:

1. Some IDs are always used for the same thing, e.g. 00 = timer task, 0x8E = on board management task
2. User applications use the d's:  0x2d, 0x3d, 0x4d.  This allows for mutiple applications on the same host.
3. There are standard associations with which support people will be familiar, such as 0x15 = MAP, 0x23 = ISUP.

For your convenience, the following lookup table should be cross checked with the the SYSTEM.TXT file: (Note: This is not a complete lookup table)

00		timer task
10		CTbus/SCbus LIU & clocking module
14		TCAP
15		MAP
1D, 2D, 3D, 4D  user application
20		SSD - board interface task
22		MTP3
23		ISUP
25		IS41
33		SCCP
35		INAP/CAMEL
4A		TUP
71		MTP2
81,91,E1,F1	MTP2 (SS7HD)
8E		on-board management
C1		M2PA
C2		mbm - management task
CF		S7_mgt - management/config task
D0		SCTPD
D1		SCTP
D2		M3UA
DF		LIU/MTP2 status
EF		S7_log - warnings/indications 

Here are a few tips to consider:

• First, beware of messages going to 0 (i.e. d00 in the message). 00 is the timer task, so it will not understand messages for other layers (e.g. MAP) that are sent to it. This often results in an error. For example, the application is for some reason using 00 as its own module id instead of a valid one
• • Second, if a module is not picking up its messages (resulting in the system being jammed), you will be able to see this with the command:

  gctload -t1

If the allocated MSGs keep increasing, it means that messages are entering somewhere, but that no process is reading them back out again.  This may happen when the SYSTEM.TXT thinks the app has module id 0x3D, but the application instead decides to use 0x2D.  A system in this state will eventually run out of message buffers (by default 200 are allocated), and then everything will stop.

Feedback

Home | Products | Purchase | Partners | Developers | Services & Support | Downloads | Contact | About Us
Legal | Privacy Policy | Sitemap | | Careers | Newsletter Signup