SX-200 + NSU Caller ID

[filutek]

We are trying to make Mitel 200-SX with NSU unit pass Caller ID info on 2 x PRI lines connected to the NSU. So far - no luck.
The system passes on "name" as configured by the user, it did it when we inherited it.
We tried adding *4*04*05*4 string in the form 22, but this changes nothing in system behavior (we can read Caller ID on the other end of PRI lines)
Are we missing something?
There is a possibility that the NSU somehow blocks the message, but here we have another problem:
- installers did not leave IMAT tool, I believe we need 7.3 or newer, how can we get it quickly?
- we have no username/password for NSU, is there a way to reset those values to known defaults?
We are dealing with inherited system, a real mismatch of parts - some cards date back to 1992, many components were replaced around 1998 - then system was upgraded to SX-200 + NSU in 2007, it supports approx. 200 users.

 

[kwbMitel]

You need a *6 code for form 22 to send desktop digits.

*4*6*04*05*4 in your example.

The NSU does not have a security, IMAT will do it for you.

IMAT will be on the install CD.


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[filutek]

Thanks a lot, kwbMitel, we tried it, we have *6 but there is no change, the name is forwarded, the CID number of the extension is not going up the PRI.
We ran through all the forms and manuals again - and we are puzzled again... Is there another option in the forms that might be causing it? We are new to Mitel, parachuted on the problem from the data comms side, but normally we can read and understand manuals; this one has us all beaten so far.

Also - is it possible than NSU is intercepting it? Our NSU software version is 4.1

IMAT seems to be another problem: company which installed the system for us did not leave the installation disks, when I asked them for them their response was: "IMAT is for Mitel certified technicians only" - of course I will dispute that, we bought the system, so all parts - including installation media - are our property, but that can cost us time; any suggestions where I could purchase this software?

 

[kwbMitel]

Your claim of ownership is not as black and white as you might think. For example, Mitel considers you the registered owner but you do not have the right to resell without reregistering ownership. That doesn't stop anyone but that is the party line.

As for the NSU blocking the ID. Unlikely. The name is being sent and the method for blocking digits would block the name as well.

connect to the NSU Maint port using a VT-100 terminal emulator and a straight thru 9 pin RS232 cable (hyperterminal will do)
Set the speed at 38400/n/8/1
press enter to get a prompt
at the prompt type: option +dispcall
exactly as above, it doesn't like typos and wont like backspace.
Make a call and observe what is being sent to the telco as far as name and number.
report back on the results

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[filutek]

Thanks again! Here's the result of "option +dispcall", and then dialling 2270 from the Mitel handset in the phone room:

option +dispcall

| info AFC | 09/01/23 07:17:27 | CPAPICVT get_dms100_addr_type: cannot
determine address type for dir number 2270. | 10
>>> >>> OUT: 09/01/23 07:17:27 (PHONE ROOM) @ 2270

No caller ID (should show 1287, that's the phone used). It looks like the caller ID is being stripped off before it gets to the NSU, but I don't know enough to say for sure.

A little bit of a background:
- Mitel is our old PBX; it used to talk to telco directly using 2 x PRI;
- Now we connected it to our new PBX (Asterisk) using the same 2 x PRI interfaces on Mitel;
- New PBX talks to telco and acts as a gateway for Mitel.
- ext. 1287 is on the old PBX, 2270 on the new one, so for the Mitel it is an external call.
This config looks like a good idea, because we do not have to scrap and replace perfectly operational SX-200 and all the handsets, but still have most of benefits of IP telephony, if we could only make the Mitel do what we need done - pass the CallerID on the PRI line.Stll puzzled, what ate our CID?

 

[filutek]

Here is another problem we encountered when trying a workaround to the previous one:

We thought we could get around the PRI caller ID problem by hooking up a third T1 in E&M mode between the SX-200 and Asterisk. Asterisk sends calls down the PRI to SX-200, SX-200 handsets are configured to forward on busy/no answer to a speed dial, and the speed dial routes out the E&M to Asterisk with a modified digit entry of "64*6#57*01#60*02#".

The handsets can dial the speed dial and get to Asterisk through the E&M. Mitel handset-to-handset calls even forward properly. But if a call comes in from Asterisk to Mitel, it never forwards. After 4 rings the "Forward" softkey disappears from the called handset and it just keeps ringing. It's like the Mitel decides at the last minute that it's not allowed to forward out the E&M if the call came in the PRI.


BTW, for the PRI, modified digit entry is currently *4000*6*4*04. Without the
"000", if we dial a 4-digit number that is routed out the PRI, the Mitel only sends the last digit up to Asterisk. (e.g. "1602" -> Asterisk receives "2")

Also, at the PRI level, it looks like Mitel is sending the calling party display name but not the number. We have Q.SIG supplementary turned on and switchtype is DMS100 on both SX-200 and Asterisk (although I guess it could be mismatched on the NSU; we can't tell without IMAT, or at least we do not know how).

 

[kwbMitel]

I suspect the CPN tables in the NSU are incorrectly configured. The trace above indicates that you are only sending 4 digits. A CPN table should be set up to send the areacode(NPA) and officecode(NNX) as well.

e.g.
Digits to match Digits to substitute
2200-2299 204555XXXX

The simplest way to connect is via the ethernet port on the NSU (requires crossover cable if direct to PC)

The default address on the NSU is 192.168.1.1

If this has been changed you may need to reboot the NSU and observe the IP address via the maint port. There is a command to determine the IP without reboot but I can't remember it off the top of my head.

I have placed a copy of IMAT for the SX200ICP rel 4 at the link below:

https://www.yousendit.com/download/WnBTTG01bWdsUjlMWEE9PQ

Also included is a powerpoint presentation that I created several years back for training purposes.

Instead of creating a new database as the presentation indicates choose the connect option and connect via ethernet.

Due to the age of your system it is likely that it will warn you that the DB is of an older version. This is ok.

When saving the DB back to the NSU it may ask you if you want to upgrade or leave as is. Do not upgrade.

Reboot after saving.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[filutek]

Big thanks kwbMitel; I will schedule reboot, try it and report back.

 

[kwbMitel]

The command to get the IP address without rebooting is:

show boot


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[filutek]

Thanks again!
It looks like I will have all stakeholders agree to short downtime on Monday evening - for reboot, so we are using the time to learn as much as we can in a non-destructive manner.

It is getting really interesting...

There are two T1 PRIs from SX-200 to Asterisk.

PRI #1: slot 5/6 in the mitel; Asterisk uses this first when placing calls to Mitel
PRI #2: slot 5/8 in the mitel; Mitel uses this first when placing calls to Asterisk.

Looks like they must be configured wildly differently in the NSU. We discovered this by accident when we removed PRI #2 from the outgoing trunk on the Mitel. Suddenly, it started passing caller ID. Not the right caller ID (always 613-719-xxxx - one of our DID's chosen at random); it must be being translated somewhere we canot see, hopefully IMAT will tell us.

What's interesting is they're configured incompatibly. You can't make the SX-200 dial out properly on one of them and still dial out on the other.
So although Asterisk can use both PRIs to send calls to Mitel, Mitel can only use one of the PRIs to send to Asterisk. Used to be PRI #2, now we've reconfigured things so it's PRI #1.

Now, checking the logs. The few times outgoing calls spilled over to PRI #1 this week, they failed because of the extra "000" (call-by-call digits) that PRI #2 required in the modified digit table. Caller ID was the same 613-719-xxxx.

Bottom line: we think we need to run IMAT on Monday night and fix the PRI configs. For now there are only 23 outbound channels for Mitel, which is no good; we have to have them all before we can migrate VM for Mitel users to Asterisk - now it is on nearly dead Octel, using 8 analog trunks to connect to SX-200.

Also, we changed N from 0 to 4 in the dial-in trunks form for all of our PRI channels, but I don't think this made a difference. Hasn't hurt either. As far as we understand it, it seems to control number of expected digits for inbound calls, and possibly something we do not understand about TIE vs DID mode for outbound calls.

Also also -- no change on the forwarding problem. When a call comes in PRI #1 to a Mitel handset, and the handset is set to forward to Asterisk either through the PRI or the T1 E&M (we still have it while learning), it just doesn't forward; again - cannot migrate VM until it does :-(

(We are trying to keep the Mitel, nothing wrong with it, just a bit of a mess in programing, that can be probably untangling once we learn enough to do it; but - we really want to scrap Octel - end-of-lifed already and we never really liked it, also - we have to have one VM to forward voice mails)

 

[kwbMitel]

It might be time to consider hiring some trained help.

This doesn't look like something you want to fool around with by guess work.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[filutek]

I wish I could kwbMitel; if I could only find really trained help, I would gladly do it; so far - every attempt to do exactly that resulted in more problems... Now my employer simply doesn't trust local "support" guys and I cannot really blame them...
Originally all we wanted to do was enable IP trunks between 3 locations, our "trained help" (certified and all) was unable to do it for... 12 months, over low latency 100Mbps fibre; before that - two subsequent sets of "trained help" were unable to sort out CID forwarding Mitel-to-Mitel over dedicated T1's for... 7 years.
I am not joking, this is where this mess came from, every subsequent technician made things just a little bit worse, usually after causing some unplanned downtime. The sad part: the equipment is fine, when it works, it just works, no silly hiccups.
We listened to advice, bought more equipment, upgraded things, no luck, system never worked up to designed (and promised) specifications.
Eventually - after years of disappointments - the company fired third subsequent "support" outfit at the end of the year and... we fixed our multi-site problems on our own in two weeks (this is how my team became part of this project).
If there was anybody like you in the area - it would take me 5 to 10 seconds to decide, I am wasting days of time of really sharp data network gurus on learning something somebody out there already knows and could do faster and better, but... we tried for years and failed to find anybody worth hiring, so we gave up.
Our original problems are solved, the current issues are essentially my fault: I don't want to scrap perfectly good, reliable equipment from a respectable company, just because it was programed by a drunk skunk ;-) I might be wrong, we might have to do it after all. Shame. But - I will try to learn some more and avoid it...