atcomsystems.ca/forum Forums TDM Business Telephone Systems Mitel Telephones & Systems Mitel SX200 - how to view debug logs

I'm working on getting a PRI setup on my Mitel SX200, outgoing calls are working, but inbound are failing. Debug logs from the SIP T1/PRI gateway show the PBX rejecting the call. Can anyone tell me how to view the logs or enable debugging on the Mitel so I can view the call trace to see what's going on? Thanks in advance.

from a Mitel bulletin:

With the introduction of the PRI on the embedded modules on the SX 200 ICP, the method in which to activate the debug commands have changed. On the NSU or the PRI card, you would connect directly with a serial cable and type commands such as option +dispcall to see different types of information for troubleshooting.
With the embedded PRI module, these commands are input in CDE form 43. To view the output of these commands, you have to secure telnet to the SX200 ICP on port 2002.
This is a list of the commands which are useful for troubleshooting.

pri chan state It gives a snapshot view of status of the link. Similiar to the Option state on the NSU

pri discall on It allows you to see info on calls in both directions Similar to the option + dispcall on the NSU

pri discall off Turns off the output of this information Similar to option - dispcalll on the NSU

pri cause on Allows you see the cause code information Similar to option + cause on the NSU

pri cause off Turns off the output of this information Similar to option - cause on the NSU

tsp l2l3 on Turns on the Layer 2/3 trace Should only be done on Request from Mitel


tsp l2l3 off Turns off the Layer 2/3 trace

How are you routing the incoming calls?

Have you double checked all of your settings to make sure they match the far end settings as to protocol, number of digits and all? Does anything show up in the SMDR or does it not even get that far? As western asked, are the calls routed to a valid internal destination?

Hi Panda, thanks for the info. Please forgive my ignorance, my forte is IT, not much experience with telecom, especially with PBXs. I'm not sure which type of card I have. There are two T1/E1 ports on a daughter card that slides into a main full-size card, which also has two 10/100 Ethernet ports and the DB9 Maintenance port.

A direct serial connection to the maintenance port prompts for a terminal type, then I can access CDE or Maintenance, but seemingly nowhere to enter the commands for debugging.

Form 43 is "T1 Link Assignments" and again I don't see where I would enter the debug commands.

Help? Thanks again.

Hi westerntelephone,

Again, excuse my ignorance being that I'm no Mitel expert, but I believe it is setup utilizing the Digit Translation Table and routing to a single internal extension (for now, testing purposes). The T1 is sending the last four digits of the DID to the PBX.

Hi Steve,

My PBX vendor has checked all settings against what the SIP gateway vendor has in their device. The T1 link is established, so I don't think it's anything at that level, and outbound calls works, so I believe it's some kind of routing issue.

The PBX vendor was able to get incoming calls to come through, albeit they weren't routing to the intended extension, they were ringing through to the front desk (this is a hotel). They were modifying how many of the incoming digits were sent and how many were being stripped, though they couldn't find a pattern to make sense of it and route it correctly. They seemed to think they weren't receiving the correct four digits of the DID coming from the gateway, although the gateway debugs show exactly that. That's what I'm trying to confirm by accessing debugs on the PBX side.

Thanks.

You did not specify which Mitel SX-200 you are trying to have this work. Is it an ICP or EL?

Please don't take this the wrong way, but you are treading into a very complex and technically challenging area. You can, by doing a very minor programming change, bring the system down completely. I would encourage you to contact a Mitel dealer in your area to make sure this circuit and equipment is installed properly. I have installed hundreds of PRI and T-1 circuits in Mitels and, even if you know what you are doing from an experience standpoint, these circuits can be problematic due to subtle differences in carrier and switch specs that don't quite work with the Mitel.

Rcaman

Hi Rcaman,

It is a SX-200_ICP_5.0.0.18 AX.

I'm well aware of the repercussions of making config changes, same applies to my industry. I'm just trying to collect the data needed to resolve the issue and present it to my vendor. They don't know how to read the debugs/logs.

Thanks

The logs, while valuable, will not necessarily help in resolving the problem. Issues like wink timing, E&M setup and tear down, dial tone expected, toll office, DTMF, NI1, NI2, AT&T, DMS and a host of others are what make this a difficult problem to resolve. Something as simple as 250 ms. wink vs 300 ms. wink is enough to cause problems. How did you program form 15? Did you specify how many digits are expected and if you are stripping off incoming digits or adding digits, have you done that? How did you program form 19 for illegal and vacant numbers? Did you program a DID answer point? You see, there are a host of issues that must be addressed to properly resolve the problem.

I have found, in the case of DIDs not going where they are supposed to go there is usually a conflict in form 15. Also, the timing is CRITICAL if these are wink start trunks. You MUST make sure the carrier is supplying winks and correct timing. This is why I suggested a Mitel dealer take this problem on because, without a little experience, the carrier can tell you all kinds of BS and none of it is correct. Learn this, if nothing else, the carriers LIE. Your PRI should be ESF, B8ZS and should be set up as E&M. I have actually seen the PRI delivered as ESF and AMI. Any telephone crafts person will tell you this is impossible, but it can leave the CO or the POP as B8ZS and some repeater or interface module, in line, can be optioned out for AMI. It happens. To really see what is actually happening on the span, you should have a Tberd or some other piece of test equipment that can accurately tell you what is really happening. Logs will tell you a little, but the true proof is in a span analysis that can only be done with a test instrument, like a Tberd.

Rcaman