Changing dest code cures call processing lockup on PRI circuit 2

[cowenby]

We have a Modular ICS with about 160 stations and installed an ISDN-PRI 8 months ago. Shortly after we installed the PRI we started experiencing problems where the MICS would stop process incoming or outgoing calls on the PRI. Outbound callers would hear nothing (dead air). Inbound callers would reach a busy signal. The problem would go away after we power cycled the MICS, but we'd have the same problem again 5-8 days later.

After 7 months of troubleshooting, changing hardware, upgrading software and basically re-building and re-programming the entire system, a simple solution was found. The destination code for outbound calls was changed from "9" to "9Any". We have had no problems since this change was made.

I'll not go into the technical details of the problem other than to say that the problem was caused when a user went off-hook, dialed 9 and didn't dial any additional digits for at least 11 seconds.

This problem is not universal. It occurs only when a DTI is connected to a specific type of central office equipment using a specific protocol.

I hope this tip helps to saves someone from 7 months of misery.

 

[eddaphoneguy]

Thanks for the post cowenby! This is sure helpful. I've been experiencing a few wierd and odd problems on a MICS with PRI's, so I'll keep your advise in mind for the next time I encounter something similar.

ED
RF Communications Inc.

http://www.rfcinc.com

 

[PTerrell]

cowenby,
Did you get any alarm codes that matched your symptoms?

Last Wednesday I had the same problems with the PRI going down five or six times, but the Alarm Code 75, indicating a problem with the ISDN connection, always was given.

 

[cowenby]

Our problem was marked with multiple EVT904 and EVT799 entries in the System Test Log. These events continue to be logged even after the dest code change with no apparent ill effect.

The definitions for these events are:
EVT799: A call processing error has occurred on an ISDN line.
EVT904: A log event has been caused in the ISDN loop driver or broadcast call handler by the receipt of unexpected input.

If you are currently using 9 or any single digit as a destination code, it won't hurt anything to go ahead and change it to "9 Any". The MICS won't start processing the call until the caller enters at least two digits. This prevents the MICS from sending a call setup message to the central office with no called number, which appears to be the initiating event for the call failures we experienced.

 

[cowenby]

The only time that I recall getting an Alarm 75 was when we disconnected the cable between the Network Interface Unit (NIU) and the Digital Trunk Interface (DTI).

 

[Roldan]

cowenby,

What was the C.O. Protocol type?

PTerrell,

Are you still getting those Alarm75's?

 

[cowenby]

The protocol is National ISDN-2 (NI-2).

 

[PTerrell]

I haven't had any Alarm 75s the past week. The last Alarm 75 I saw was triggered last Thursday on Thanksgiving day, the day after I got the five or six failures.

After the second alarm on Wednesday, I reported the problem to my PRI provider, SBC. The SBC troubleshooter said that the errors were coming from our side. He used telecom jargon, and I'm just another IT guy who is taking care of the phone system. thread799-716035 ;-)

I reported the alarms to my Nortel vender, I was taught how to disable and enable the DTI module so that the PRI was reset. But they pointed the finger back at SBC...