Advanced Diagnostics - Detailed information about the Diva Diagnostic 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'.

1. 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?

1. 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?

1. 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.

1. 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.

1. 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.

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

[4] B Channel example - PPP data.

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.

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

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

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

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.