200ICP, some phones can't call 911

[acejavelin]

So I have this older 200ICP, it is 2 buildings where long-term medical patients stay (like transplant patients who no longer need to be hospitalized but can't go home yet)... with a mix of IP and analog devices.

Anyway, in the main building there are IP phones for admin extensions, 5340's and 5312's, with analog extensions for the rooms, and everything works fine. Across the street on a P2P wireless network connection there is another guest building but all the room phones are 5304's and a handful of 5312's in some office/common areas. The problem is the 5304 phones cannot dial 911/9911/8911, but all other phones in the system can, nothing shows in the display just "911" or "9911". Same COS, COR, and Tenant, and they are not using Outgoing Call Restriction, the ARS digits are correct, are flagged as Emergency numbers, and there are no COR groups assigned to those routes.

I am frankly perplexed, several phones with exactly the same Tenant, COR, and COS, are dialing the same string of digits, and it works for all device types except 5304 sets?!?!? I am no slouch in the 200 and have been installing and maintaining them since 1991, so I thought I know them pretty well, but what am I missing?

They are currently on 5.0.0.4 software, so I was thinking of upgrading them to 5.0.2.12, or possibly just going in and doing a database backup and restore.... Thoughts?

[ralph]

Can the problem be isolated to a PRI?
What happens if you route out a copper trunk?

Ralph

BTW:  I have had issues before where certain numbers couldn't call 911.   Carrier problem.

[panda]

if all other sets can route to 911 with the same tenant, cos and cor I would think it is a bug. I went through the release notes I have but didn't find that issue. What does the user hear when 911 is called? Anything on the SMDR?

[acejavelin]

I get what your saying ralph, but I think I have ruled out the PRI and carrier, a trunk isn't even being seized and no SMDR is being generated, but it is from a "good" phone. I have tried everything I can think of to isolate this to something, anything really, that I can track down, and the only commonality I can come up with is the 5304 sets...

So I am leaning towards Panda's idea that this is a bug, hoping for an upgrade early next week to the "current" release of 5.0.2.12 will fix the issue. The user get's a busy signal, no message in the display other than the digits dialed, and no SMDR record (watched maintenance status of PRI trunks, no trunk is being seized). Due to the nature of this facility they have 8911, 9911, and 911 all programmed as emergency numbers, and all produce the same results.

The one question the customer can't answer me is when it failed, or if it ever worked... This problem is a little concerning for me personally, I installed this system in 2008 when I worked for a vendor a couple jobs ago, I seriously hope this hasn't been going on for 7 years and was just never known. :/

[ralph]

What kind of trunks are you using?
If it's a PRI then it still could be a carrier and you wouldn't (may not) see SMDR.

Ralph

[acejavelin]

PRI... and actually you could be onto something there ralph... I got a sudden brainstorm and remembered that in the 200 ICP you could set the CESID (similar to the 3300), I did find some phones had the main number defined and others did not have anything defined at all, and all phones have a number defined in the CPN Substitution form as well, so I did find some differences that could be related to this issue but unfortunately the IT person had gone for the day so I had no one to test with and I am about 500 miles away from this site today.

I think I might try to get there Monday afternoon and do some more testing and upgrade software... Either way I will figure this out.

[acejavelin]

Does anyone know how to view the D-channel messages on a 200ICP with embedded PRI? Similar to a edt trace tsp l2l3 on the 3300... I have sneaking suspicion the carrier is rejecting these calls but I need to prove it.

Sent from my MotoG3 using Tapatalk

[panda]

is this what you are looking for?

Body/Solutions
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

Shell restarted
-> 2013-03-25  07:05:26  5/2/23VTS --> PSTN: DNIS/Called # = 613-222-1234

2013-03-25  07:13:35  5/2/1VTS <-- PSTN: DNIS/Called # = 1234 ANI/Calling # = 613-222-1234

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
This is the only one that really shows anything

tsp l2l3 off Turns off the Layer 2/3 trace

To turn these commands on or off, log into CDE form 43 and go to the bay/slot of the link you want to run these command on, and tab over to the COMMENTS field and type them in. To view them, secure telnet to port 2002 on the controller.
Log into installer level only using proper telnet

[acejavelin]

is this what you are looking for?

Body/Solutions
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

Shell restarted
-> 2013-03-25  07:05:26  5/2/23VTS --> PSTN: DNIS/Called # = 613-222-1234

2013-03-25  07:13:35  5/2/1VTS <-- PSTN: DNIS/Called # = 1234 ANI/Calling # = 613-222-1234

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
This is the only one that really shows anything

tsp l2l3 off Turns off the Layer 2/3 trace

To turn these commands on or off, log into CDE form 43 and go to the bay/slot of the link you want to run these command on, and tab over to the COMMENTS field and type them in. To view them, secure telnet to port 2002 on the controller.
Log into installer level only using proper telnet

Thanks! I think that is what I need... I need to see the 200 attempting to send the call and Telco reject it, if that isn't the case it will certainly narrow down the possibilities. I will be on site this afternoon and try it.

Sent from my MotoG3 using Tapatalk

[acejavelin]

Just an update on this... It was the carrier, the rooms had a different DID range that was being sent as outbound CPN that is different than the rest of their numbers, the carrier did not have a route to 911 from that area code and prefix. After they built a new route we tested it and everything is working. Thanks for everyone's help.

Sent from my MotoG3 using Tapatalk