Technical Helpweb

- more articles

Advanced Diagnostics - Detailed information about the Diva Diagnostic Trace

Diva Advanced Diagnostics - Main Menu
How to take a Diva Trace

Detailed Information on what a Diva trace contains

The Dialogic Diva Diagnostics utility produces a lot of output, most of this information is only useful to a developer, but some of the more useful types of message are listed below.

Particularly the 'Cause' information is of interest. Below is an example of what this would look like in a trace. The contents of your message will almost certainly be different from this one, so just look for the word 'Cause' and take note of the two groups of letters and numbers following 'Cause' - in this case '82' and 'd8'.

9:12:44.684 - EVENT: Call failed in State 'Outgoing call proceeding'
                     Q.931  CR8003 DISC
                            Cause 82 d8 'Incompatible destination'

The first byte '82' contains 'location' information - where the message comes from - while the second byte 'd8' is the 'diagnostic'.

Make a note of the two 'Cause' codes (82 d8 in the above example) and enter these codes into the ISDN Diagnostic Code Analyser. The code analyser will show you where in the network the problem was reported from, describe the problem and suggest solutions.

You can often tell a lot about the mode of failure by only looking at the SIG-X and SIG-R messages. Look out for these messages:

Some common types of bearer capabilities (present in the SIG-X SETUP message) are:

Suggested Strategy for finding problems in a Diva Trace

Layer1 & Layer 2 problems:

STEP 1: Use the Diva Trace to find the message "LoadAdapter" in the Initialisation sequence.
To capture the initialisation sequence of the Diva board follow the instructions on the page How to take a Diva trace

This LoadAdapter message reports that the Diva board is installed and loaded correctly.

Also look for the message L1_UP in the trace. If you do not see this, then the Diva board is not even talking to the network at the physical layer. Check the cable and the switch type configuration.

STEP 2: Look for SIG-EVENT FFFF messages.

This shows low-level problems with the card. Look to see if there are any D-X or D-R messages; if there are not, then the DIVA is not communicating with the NT1 or the network.

STEP 3. Quickly scan through the trace and look for "EVENT".

This may show a local or network failure of some kind.

Layer 3 Problems:

STEP 4. Make sure there is a SIG-X containing "SETUP"

This indicates that a call is being made by the Diva board. If there is no SETUP, perhaps the application never tried to make a call, or perhaps there is a layer 2 problem (see above).

STEP 5. Check if a SIG-R came in containing "CONN".

If the SETUP receives a "CONN" (CONNECT) as a response, then a "B" channel was successfully connected. If the SETUP gets "DISCON" (DISCONNECT) as a response, then there is a problem with the network, or with the equipment at the far end. DISCON normally has Q.931 cause codes to tell you what the problem is.

STEP 6. If the cause of a "DISCONis not obvious, then check the SETUP message"

Make sure that the ISDN numbers are correct, and also that the Bearer Capabilities look right.

STEP 7. If the "CONN" event is received then look for "B-X" and "B-R" messages.

If you can see one or more of these, then the ISDN network and connection are OK, and you need to go on to the next stage.

Higher Level Problems:

1. If you see B-X messages, but no B-R messages, then this means that DIVA is sending data (e.g. PPP frames), but the remote equipment is not responding. Perhaps the remote equipment is not using the same protocol on the "B" channel?

2. If the B-X and B-R data starts with "FF 03" then this is PPP protocol, and the next logical step is to analyse the PPP to look for negotiation problems.

For example, are both ends using the same protocol (IP, IPX, Netbeui etc), does the authentication (i.e. PAP, CHAP) succeed?

3. All "B" channel protocols (X.75, X.25, V.120 etc) have their own activation sequence, so at this stage you need to start analysing the B-channel data with protocol-specific tools. Needless to say, it is important to have some idea what kind of protocols the equipment at the other end of the link supports.

You can sometimes guess what the protocol is from the first frames sent and received, for example:

• B-X or B-R Frame contains 01 3F or 03 3F (SABM frame)
  This could be X.75 (LAPB) or it could be X.25 (which needs to activate LAPB first).
• B-X or B-R Frame contains 08 01 7F (SABME frame)
  This could be V.120 connection. Note that sometimes other protocols are carried inside V.120 (PPP or asynch PPP for example).
• B-X or B-R Frame contains FF 03
  This is quite likely to be PPP.
• B-X or B-R Frame contains 7E FF 7D 23
  This is quite likely to be Asynch PPP.

Example frames from traces:

[1] D Channel example.

11:18:07.942 - D-X(008) 00 81 08 0A 08 01 06 5A

This is a frame transmitted (X) on the "D" channel. The first four bytes are actually a LAPD header (this is a LAPD "I" frame) and the next four are the Q.931 header (0x5A = RELEASE COMPLETE).

[2] D Channel example.

11:18:07.964 - D-R(003) 00 81 73

This frame is a received (R) LAPD frame (in this case a "UA" frame).

[3] B Channel example - X.75 data.

11:18:07.892 - B1-R(068) 68 bytes
0x0000 03 20 01 00 47 0D 00 83 30 31 38 31 32 38 33 39 . .G...01812839
0x0010 39 39 39 00 00 00 00 00 00 00 00 00 00 00 00 00 999.............
0x0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0040 00 00 00 00 ....

This frame is a received on "B" channel 1.

[4] B Channel example - PPP data.

16:12:17.275 - B1-X(014) 14 bytes
LCP : id 2, len 10 ==> Configure-Request
- Magic-Number 0x0007A77B
0x0000 FF 03 C0 21 01 02 00 0A 05 06 00 07 A7 7B ..@!........'{

This is a transmitted frame on "B" channel 1. Outgoing frames are truncated, if they exceed 28 bytes. As you can see, DITRACE interprets some of the data (in this case PPP), and puts a decoded version before the data buffer itself.

[5] B Channel example - PPP data.

16:12:17.261 - B1-R(044) 44 bytes
LCP : id 1, len 40 ==> Configure-Reject
- Async-CC-Map 0x000A0000
- Protocol-Field-Compression
- Addr-and-Control-Field-Compression
- Callback ==> Location is determined during CBCP negotiation
- Multilink-MRRU 1500
- Multilink-Endpoint-Discriminator
-- Locally Assigned Address
0x0000 FF 03 C0 21 04 01 00 28 02 06 00 0A 00 00 07 02 ..@!...(........
0x0010 08 02 0D 03 06 11 04 05 DC 13 13 01 98 01 00 00 ........\.......
0x0020 7B A7 07 00 4C E3 F0 C3 C3 22 00 00 {'..LcpCC"..

Here the PPP LCP header has been decoded by DITRACE, and the LCP Options are all interpreted to save you doing it by hand.

[6] SIG example - DISCONNECT

11:18:07.908 - SIG-R(008) 08 01 06 45 08 02 80 90
Q.931 CR0006 DISC
Cause 80 90 'Normal call clearing'

This is a common type of frame you will be looking for in the trace. It shows that a Q.931 DISCONNECT has been received (i.e. a call has disconnected) and the Cause code is interpreted and shown in English.

[7] SIG example - SETUP

11:18:06.753 - SIG-X(027) 08 01 06 05 A1 04 02 88 90 18 01 83 70 08 81 32 38 33 39 39 39 39
Q.931 CR0006 SETUP
MORE
Bearer Capability 88 90
Channel Id 83
Called Party Number 81 '2839999'

This is a call SETUP frame, as decoded in a SIG-X element. This shows a call attempt being sent to the network by the DIVA card. You can see that the number being called is "2839999". The Bearer Capability field shows the type of call being selected.

[8] CAPI Example - CAPI_PUT_MESSAGE

11:18:06.732 - CAPI20_PUT(026) APPL 0001 0000:00000001 LISTEN REQ
52 00 00 00 00 00 00 00 00 00 00 00 00 00

CAPI_PUT_MESSAGE shows a message being sent by an application to the DIVA card's CAPI 2.0 interface. Then numbers show the application id, the message number and the PLCI/NCCI of the message, then the last thing on the line is the CAPI message type itself, in this case a LISTEN_REQ. Message-specific data (if any) is on the following line, and you can interpret this with the help of the CAPI 2.0 specification.

[9] CAPI Example - CAPI_GET_MESSAGE

11:18:07.657 - CAPI20_GET(015) APPL 0001 0024:00000201 INFO IND
07 80 00

Here you can see an INFO_IND message being read by the CAPI application. The data on the next line, tells what kind of information element was seen by the DIVA card (in this case 07 = Q.931 CONNECT).

[10] EVENT Example.

16:51:07.913 - EVENT: Call failed in State 'Outgoing call proceeding'
Q.931 CR8003 DISC
Cause 81 d8 'Incompatible destination'

It pays to quickly scan through the trace for EVENT messages, since this can quite often show you the fault. Here, a DISCONNECT is being received in response to a SETUP, and the 'Incompatible destination' cause code shows that the user has made a digital call to a non-digital destination (e.g. a phone).

[11] MDL-ERROR Example

0:0032:776 - D-R(004) 02 B7 01 03
0:0032:777 - D-X(004) 02 B7 01 03
0:0033:365 - D-R(003) 02 B7 7F
0:0033:365 - MDL-ERROR(F)
0:0033:366 - D-X(003) 02 B7 73
0:0035:492 - D-R(003) 42 2B 7F

In this example, the first two lines show normal D-channel idle activity in both directions, and then at line 3, the network resets the LAPD level by sending a SAMBE.   This unexpected reset is detected by the Diva card as an MDL error (according to the definitions for ISDN, for example in the ETSI specification).  The type of the error is 'F', which means 'received SABME, Peer initiated re-establish'. 

More information on MDL Errors.