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

Hi Rcaman,

Thanks for your continued input, much appreciated. I've attached some screenshots of the forms you mentioned above, as well as a couple shots showing the T1 config on the gateway device. Anything jump out at you as incorrect or potentially causing issues?

Also, can you advise me on how to obtain the debug logs as I inquired originally?

Thanks.











[img]https://dl.dropboxusercontent.com/u/64345/mitel/Form42-2.PNG[/img]
[img]https://dl.dropboxusercontent.com/u/64345/mitel/GatewayT1-1.PNG[/img]
[img]https://dl.dropboxusercontent.com/u/64345/mitel/GatewayT1-2.PNG[/img]

Form 15. Why is the 1st trunk programmed for different received digits and digits to be absorbed? (N and M)

Hi westerntelephone,

I believe because of this:


This is why I'm trying to figure out how to view the debug logs to examine a trace of a test call and see exactly what is being sent to the PBX across the T1 from the SIP gateway.

Thanks.

You need a certified Mitel technician in there.

form 15:
N - is the number of digits to expect from the CO
M - is the number of digits to be absorbed
X - is the digit to insert

assumption only, N is 4 M is 0 and X is blank

Hi Panda,

Thanks for the info. Can you please see my reply to your first post above, questioning how I can make use of your info regarding accessing the debug info?

Thanks.

just say your post, make sure you have *1 in form 2 option 67, that is the X in form 15, digit translation

Panda,

Yes, I confirmed it is programmed as you stated.

Again, I believe the accessing the debug logs is critical to solving this issue. The debug info from the T1 SIP gateway provided a great deal of useful info, and I believe the Mitel logs will do the same. Can you clarify what you posted earlier?

Thanks.

Then form 55 for translation to destinations

type the commands in form 43 in the comments field to turn the options on but remember to go back in and turn them off. If you telnet in you will see a lot of info. This one is the one I use the most to show the layer 2/3 info:
tsp l2l3 on

You must get into the maintenance side and pull a status report of the bay, slot and circuit of the PRI module to get the debug.

First off, your wink timer should be the same for incoming and outgoing. It isn't.

Second, you are inserting a *1 along with the 4 digits coming in. What does *1 do?

The T1 SIP is missing any timer data.

The channels are all COS 10. What do you have enabled in COS 10?

Too many questions and not enough answers.

Rcaman

Hi Panda,

Yes, thank you, I figured that out after reading what I believe was a post from yourself "pandabear1" on the Tek-Tips forums where you included the part about putting the string in the comments. It never even occurred to me to enter it there; to me a comment is a comment, apparently Mitel thinks differently.

Anyway, I was able to get a trace of the call and confirm that the Mitel is rejecting the call. The question then is why?

I played around with different N/M/X values in Form 15, and found the following:

N - "should" work with a value of 4, but doesn't seem to make any difference
M - "should" work with a value of 0, but 6 is the only number than yields a result, though not the correct result
X - "should" be *1, but that doesn't seem to make any difference

The combination of M = 6, with N and X set to any value or no value, results in incoming calls ringing to the front desk (again, this is a hotel). Theoretically with N = 4, M = 0, and X = *1, the Digit Translation Table should then direct the call to extension 6002 (yes, this is a valid internal extension). If I use those settings for N, M, and X, the incoming call fails. If I set M = 6, the call rings through to the front desk.

The trace shows the following on an incoming call:

1 01101100 Information Element: Calling Party Number:
2 IE Length : 12 octets
3 0------- Extension bit : Continued
-000---- Type of number : unknown
----0000 Numbering plan : unknown
3a 1------- Extension bit : Not Continued
-00----- Presentation : Allowed
---000-- Spare
------00 Screening : User provided, not screened
4 ******** Phone number : [XXXXXXXXXX]
1 01110000 Information Element: Called Party Number:
2 IE Length : 5 octets
3 1------- Extension bit : Not Continued
-000---- Type of number : Unknown
----0000 Numbering plan : Unknown
4 ******** Phone number : [8682]

In the above trace sample, I replaced my number with XXXXXXXXXX for security reasons, but it did show the correct number I was calling from. The Called Party Number of 8682 is the correct last four digits of the DID on the T1, so it appears the gateway is passing the correct four digits.

So why are the calls not following the intended path?

Any insights are greatly appreciated.

Thanks.

I only see one setting for a Wink timer? Also, from what I've been told by tech support for the T1 SIP gateway, Wink does not apply to a PRI circuit?

The *1 makes use of the Digit Translation Table to the route the DID to the intended extension, correct?

COS 10 is configured, is there a particular item I should be checking in there?

I should also mention that this PBX was previously configured for a "regular" T1 circuit from the telco, we then switched to POTs lines, now switching it to a PRI from a VoIP provider via a gateway device. Of course the PBX vendor is blaming the gateway device, and vice versa.

Thanks.

try this:
N - 10
M - 6
X - *1

so a number of the hotel is 613-592-2122 so you would expect 10 absorb 6 and be left with 4, the 2122
In form 55 you would have incoming digits are 2122 DiD prefix is 1 and your day mode night modes would be where you want to terminate the call, say a LDN on a console in day mode for example.
remember to turn the debug off in the comments field of form 43

See, this is where it is like banging my head against a wall.....E&M requires some type of start signalling. It DOES NOT matter if it's a special circuit E&M, a T-1 E&M or a PRI E&M. Every E&M MUST have a start type. It may be immediate, or delay or Wink. The MOST common is wink. Your "provider" MUST provide a wink signal somewhere between 200 ms and 300 ms as that is what you have the E&M programmed for in the Mitel. Any other signal will yield goofy results like you are experiencing.

Look....a vendor meet is required here. Have the provider send a tech out with a Tberd or some other span tester that can tell you, without a doubt, if there is wink start and how many milliseconds the duration is. Have the Mitel dealer there to make sure all the forms are set up correctly, including form 3 and COS 10, form 15, form 19, form 45, etc.

You can't just arbitrarily assign a value to form 15 M. It MUST BE the exact number of digits the provider is sending. Just plugging in random values is making one very large and very dumb rabbit hole. How many digits are being sent? Usually, DIDs are sold in blocks. So, if, as an example, your room numbers are floored, meaning every floor has the exact same number of rooms and they all start with 00 and end with 29. So, floor 1 would have rooms 100-129. 30 rooms. Floor 7 would have rooms 700-729. See the pattern. Let's say, as an example, you purchase a block of DIDs from (AC)-XXX-2100-2730. M=4 digits, N=1 digit and x is blank. Believe me, the Mitel will route every call to the proper room, without fail. BUT....this is an example. What is the block that was purchased?

Rcaman

looks like from the trace you are receiving 10 digits, I would guess the start types are correct or you would not be able to make outgoing calls. Trying something is better than doing nothing at all if you cannot receive any calls.
Good luck

Actually, the key is in the wink timers. Outgoing is set to 300. Incoming is set to 200. If it works outgoing but not incoming, that may be a good place to start. The sent digits is the other area that needs addressed. Sending 10 digits is not necessary nor is it normal.

Rcaman

The *1 would be to send the calls to the Form 55 Digit Translation Table so I would hope that it has been programmed correctly. Without an entry there the calls would route just on the 4 digits received. If they match a number in the system then the call should complete. Are your extensions different than the DID numbers?

The problem here is the OP may not know enough about the programming or system to provide us with proper answers. He thinks the Mitel debug logs will lead him in the right direction. Little does he know Mitel's debug logs are next to meaningless as Mitel does not use standard notation and many of the values found in debug have to be translated even when Mitel's own engineers read them. They have some kind of "on the fly" compiler that allows them to make some sense of the logs. This problem is actually an easy problem to resolve IF the person working on the problem is a telephone crafts person.

Rcaman

The issue is now resolved.

COS option 801 Incoming Trunk Call Rotary was disabled. Apparently this is required for PRI trunks. I enabled it and calls are now coming through.

Thanks to everyone for your feedback.