Mitel Diagnositics Guide

[BobbyMitel]

All -

I looked around and didn't see anything.  Is there anything out there that is a guide or a "Wiki"?  Do you need to download additional software to read in better?

Thanks
Bobby

[ralph]

Other than the Tech Hand Book? 
Or the help files for the command line?
I don't know of a Wiki for that.

Because of the complexities and variations of the different systems I would think that if someone was to sit down and do a Wiki it would look a lot like the help files.

There may be some favorite diag tools (commands) we all use most often,
These are the ones I use pretty much everyday.
Such as
Alarms
Show Fault
Stat
SMDR
Busy/RTS


Ralph






 

[BobbyMitel]

Thanks Ralph. That's good info.

Basically we have a location that has 2 buildings and random disconnects (20-30 seconds) on the phones. The PRI is not falling and Mitel says they don't see anything. I jumped into System Admin - Maintenance and Diagnostics - System Diagnostics Report and download the 6mb TAR file. When I open it, it has a bunch of random files and folders but it's impossible to read.

[ralph]

You won't find what you're looking for in the diag files.

First thing I would try to do is find out which side the Mitel sees the disconnect from.
There is something you can turn on is SMDR that will help.

Here's the text to help you set it up.  Note: this does not survive a reboot.

MN00136558 (2K) and MN00136186 (3300ICP) have added an optional indicator "<" or ">" in the first column of SMDR to show which party disconnected a trunk call.


The indicator overrides the long call indicator field (column 1) when enabled.
The indicator works for calls of 5 minutes or less per the dpar.

The command on the SX2000 maintenance terminal on either platform to enable/disable the indicator is:
 lldcli smdr_disc [ on | off ].

Do not use brackets or pipes around "on" or "off" (see sample below).

When on, < or > will appear in the 1st position in the SMDR when the call is less than 5 minutes in length.

<   indicates we, the pbx, cleared the call
>   indicates the far end cleared the call.

This is released in LW34.2.5.2 (34.2.5.3) and 7.0.20.13 (7.0.21.4).


Sample commands & test call from 3300ICP's  SX2000 interface:

lldcli smdr_disc on
----->  performed test call

So after you get a complaint of a dropped call then look at the SMDR.  If the arrow points to the left then it's the carrier.

Here's my guess on this:   The carrier has a T3 that your T1 ends up getting muxed in with.  Either the T3 itself is having issues or the card it's connecting to.   In the case I would think the T1 drops for a second causing your dropped calls but a check of your T1 will show no problems.

Ralph

[BobbyMitel]

You won't find what you're looking for in the diag files.

First thing I would try to do is find out which side the Mitel sees the disconnect from.
There is something you can turn on is SMDR that will help.

Here's the text to help you set it up.  Note: this does not survive a reboot.

MN00136558 (2K) and MN00136186 (3300ICP) have added an optional indicator "<" or ">" in the first column of SMDR to show which party disconnected a trunk call.


The indicator overrides the long call indicator field (column 1) when enabled.
The indicator works for calls of 5 minutes or less per the dpar.

The command on the SX2000 maintenance terminal on either platform to enable/disable the indicator is:
 lldcli smdr_disc [ on | off ].

Do not use brackets or pipes around "on" or "off" (see sample below).

When on, < or > will appear in the 1st position in the SMDR when the call is less than 5 minutes in length.

<   indicates we, the pbx, cleared the call
>   indicates the far end cleared the call.

This is released in LW34.2.5.2 (34.2.5.3) and 7.0.20.13 (7.0.21.4).


Sample commands & test call from 3300ICP's  SX2000 interface:

lldcli smdr_disc on
----->  performed test call

So after you get a complaint of a dropped call then look at the SMDR.  If the arrow points to the left then it's the carrier.

Here's my guess on this:   The carrier has a T3 that your T1 ends up getting muxed in with.  Either the T3 itself is having issues or the card it's connecting to.   In the case I would think the T1 drops for a second causing your dropped calls but a check of your T1 will show no problems.

Ralph

Somehow missed this reply.  Thanks Ralph.  I will this.

[BobbyMitel]

Ralph -

I tried to complete this via telnet and it locked me out for 3 invalid logins.  I have no clue what login it could be.  I do enter this command through telnet, correct?

Thanks

[ralph]

I'll PM you.

Ralph