| Table of Contents |
|---|
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.
...
Message type | Meaning |
LoadAdapter | This message reports that the card is installed and loaded correctly. |
SIG-EVENT | Examples: The SIG-EVENT FFFF messages indicate a low-level problem, usually to do with cabling or the Diva card not successfully communicating with the NT1 or the switch. On occasions this message can be caused by a faulty Diva card configuration. |
D-X | "D" channel messages (uninterpreted), complete with LAPD and Q.931 headers. D-X=transmitted by the Diva card; D-R=received by the Diva card. |
MDL-ERROR | These are normally low-level D-channel protocol violations detected by the Diva card. They normally indicate a serious problem with the ISDN line, your ISDN supplier's equipment or the provisioning (configuration) of the line. More information on MDL Errors. |
B-X | "B" channel messages. If the content is PPP, some decoding and interpretation is done for you. |
SIG-X | These are basically signalling ("D" channel) messages, but come from a higher layer in the Diva code, and have some interpretation of the data, e.g. call SETUPs have all the information elements decoded so that you don't have to do it manually. These are the most interesting messages if you are quickly scanning through the trace looking for a problem |
CAPI20_GET | These are the CAPI_GET_MESSAGE and CAPI_PUT_MESSAGE operations from a CAPI 2.0 application using the Diva card. Some of the values are broken-out from the CAPI message structure, and the actual CAPI message type is decoded (e.g. LISTEN_REQ, INFO_IND, DATA_B3). The first few bytes of the message (if any) are decoded on the line below. |
EVENT | These messages often amplify failed operations on the Diva card, so they are a good source of information |
L1_UP | These messages indicate that the physical layer is established (or not) between the Diva card and the NT1 (network connection). |
...
Bearer Capabilities | Application |
88 90 | 64K unrestricted digital (i.e. a data call) |
88 90 21 BF | 56K digital |
80 90 A3 | Voice call (A-Law) |
80 90 A2 | Voice call (mu-Law) |
90 90 A3 | Fax Group 3 |
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.
...
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"
...
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
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?
...
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.
Code Block
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.
Code Block
This frame is a received (R) LAPD frame (in this case a "UA" frame).
[3] B Channel example - X.75 data.
Code Block
This frame is a received on "B" channel 1.
[4] B Channel example - PPP data.
Code Block 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.
Code Block 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
Code Block
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
Code Block
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
Code Block
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'.