|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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.
|
|
|
Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.
|
|
|
Joined: Apr 2007
Posts: 339
Member
|
Member
Joined: Apr 2007
Posts: 339 |
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
|
|
|
|
Joined: May 2005
Posts: 1,006
Member
|
Member
Joined: May 2005
Posts: 1,006 |
How are you routing the incoming calls?
|
|
|
|
Joined: Sep 2008
Posts: 392
Member
|
Member
Joined: Sep 2008
Posts: 392 |
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?
Last edited by Steve Layton; 08/21/14 01:56 PM.
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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 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.
Last edited by TowerHosp; 08/21/14 04:12 PM. Reason: correction
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
How are you routing the incoming calls? 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.
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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 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.
|
|
|
|
Joined: Feb 2006
Posts: 1,716
Member
|
Member
Joined: Feb 2006
Posts: 1,716 |
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
Americom, Inc. Where The Art And Science Of Communications Meet
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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
|
|
|
|
Joined: Feb 2006
Posts: 1,716
Member
|
Member
Joined: Feb 2006
Posts: 1,716 |
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
Americom, Inc. Where The Art And Science Of Communications Meet
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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]
Last edited by TowerHosp; 08/22/14 12:35 PM.
|
|
|
|
Joined: May 2005
Posts: 1,006
Member
|
Member
Joined: May 2005
Posts: 1,006 |
Form 15. Why is the 1st trunk programmed for different received digits and digits to be absorbed? (N and M)
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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: 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. 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.
|
|
|
|
Joined: May 2005
Posts: 1,006
Member
|
Member
Joined: May 2005
Posts: 1,006 |
You need a certified Mitel technician in there.
|
|
|
|
Joined: Apr 2007
Posts: 339
Member
|
Member
Joined: Apr 2007
Posts: 339 |
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
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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.
|
|
|
|
Joined: Apr 2007
Posts: 339
Member
|
Member
Joined: Apr 2007
Posts: 339 |
just say your post, make sure you have *1 in form 2 option 67, that is the X in form 15, digit translation
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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.
|
|
|
|
Joined: May 2005
Posts: 1,006
Member
|
Member
Joined: May 2005
Posts: 1,006 |
Then form 55 for translation to destinations
|
|
|
|
Joined: Apr 2007
Posts: 339
Member
|
Member
Joined: Apr 2007
Posts: 339 |
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
|
|
|
|
Joined: Feb 2006
Posts: 1,716
Member
|
Member
Joined: Feb 2006
Posts: 1,716 |
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
Americom, Inc. Where The Art And Science Of Communications Meet
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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 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.
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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 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.
|
|
|
|
Joined: Apr 2007
Posts: 339
Member
|
Member
Joined: Apr 2007
Posts: 339 |
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
|
|
|
|
Joined: Feb 2006
Posts: 1,716
Member
|
Member
Joined: Feb 2006
Posts: 1,716 |
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
Americom, Inc. Where The Art And Science Of Communications Meet
|
|
|
|
Joined: Apr 2007
Posts: 339
Member
|
Member
Joined: Apr 2007
Posts: 339 |
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
|
|
|
|
Joined: Feb 2006
Posts: 1,716
Member
|
Member
Joined: Feb 2006
Posts: 1,716 |
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
Americom, Inc. Where The Art And Science Of Communications Meet
|
|
|
|
Joined: Sep 2008
Posts: 392
Member
|
Member
Joined: Sep 2008
Posts: 392 |
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?
|
|
|
|
Joined: Feb 2006
Posts: 1,716
Member
|
Member
Joined: Feb 2006
Posts: 1,716 |
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
Americom, Inc. Where The Art And Science Of Communications Meet
|
|
|
|
Joined: Aug 2014
Posts: 14
Member
|
Member
Joined: Aug 2014
Posts: 14 |
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.
|
|
|
|
OS 7030
by Bushmills - 09/03/24 12:42 PM
|
|
|
|
Forums84
Topics94,387
Posts639,267
Members49,800
|
Most Online5,661 May 23rd, 2018
|
|
|
|