Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

NORSTAR LOCKING UP

Status
Not open for further replies.

cdaumann

Technical User
Dec 28, 2007
10
US
I have a Norstar MCIS, 7.1xc with 2 PRI’s that is continuously generating the following event codes: EVT310-36000501 and EVT310-3A0005E3. I can clear the codes but they come right back - sometimes they’re generated 2 or 3 times per minute and other times it’s 2 or 3 times per hour. Eventually, the system will completely lock up and require a reboot.

I know what the event code EVT310 is (bad stimulus received by DTI from KSU), but does anyone know what the numbers 36000501 and 3A0005E3 mean?

Has anyone experience this type of problem or have any insight to what’s going on here?
So far, I’ve changed the KSU, both DTI cards, both combo cards and the feature cartridge.

FYI - The carrier has tested the circuits and says the problem is not on their end.

Any help or suggestions are appreciated!

 
Is one DTI clocking as Primary and the other as Secondary? If not than make it that way, and if so, reverse them.

Adversity is Opportunity
 
Definitely sounds like a programming issue if you have swapped everything out and still have the problem!
 
I tried reversing clocking before - but I followed your suggestion and tried it again (and got the same errors back)...I've even tried running on one PRI. I've also done the following:
1. replaced cables from smart jack to DTI card
2. disabled SM's one at a time to try to rule out bad module or bad set on module (since the EVT code reads bad stimulus recieved by DTI from KSU)

I have NOT changed the software PCMCIA card -- do you think it could it be something that flakey??? ...I was still thinking CO issue.

Here is the programming of the PRI card 1 & 2:
Card type: PRI
Lines: 001-023 (cd1), 31-53 (CD2)
Protocol: NI2
Bch seq: Decending (verified by carrier)
CBC routing: FX:none / 800:none
COFail: ITA-547-A
I/F levels: ISDN
Framing: ESF
Internal CSU: On
CSU line Bld: 15 (I've tried all 3 options - default/7.5 and 15)
Line coding: B8ZS
Clock Src: 1=secondary / 2=primary (have changed primary to secondary and back again)
Send name display: Y

Any ideas as to what other programming might come into play here would be very much appreciated!




 
If your smart jack is in the room, I'd leave CSU Line Build at default. Everything else looks right.

Do you receive any errors (bipolars or slips)in your CSU?

Adversity is Opportunity
 
Thanks for responding Dewey...this is what I have on errors:

both cards are error free 100%,
alarm stats = no active alarms,
LOS_CFA history = no LOS alarms,
OOF_CFA history = no OOF alarms,
card 2 has two RAI alarms on July 11th at 9:30 to 9:30 and July 10th at 10:04 to 10:04,
card 1 has two RAI alarms on July 11th at 9:37 to 9:37 and July 11th at 9:21 to 9:21 (probably when I was switching the cards around!!)
BPV's 0 (none), short term alarms = 0-ms,
AIS_CFA history = no AIS alarms

All the while I'm still getting the same event codes....
Any idea what the numbers on the event code mean?
Event code EVT310-36000501 and EVT310-3A0005E3
 
It's a s/w issue.
You need to upgrade to the latest release of 7.1, working issue 2.12
This is from the release notes.
Matches up to your problem.

Call cutoffs: 310 errors
This change was made to minimize occurrence of an error
which was being seen at a central office. When an outgoing call is made and the CO does not respond, we now send a release to the PSTN. The NI-2 specification does not require the PBX to send a release to the network. This change was implemented because in this scenario, a particular CO was locking up the trunks and not releasing PRI call references.

Hope this helps!



-SD-
 
Hey cdaumann, One thing I noticed in list of parameters was that you had a decending sequence. For incoming it should be acending, out going is decending. I had a Paetec T1 that was sending the first call in on channel 24, then 23, 22, etc. since the Northstar automatically starts outgoing on 23 or 24, just check to make sure the calls start coming in on line 1, not line 24. You could also email Nortel IT from their website.
 
Typically we choose Descending and the Telco will be Ascending.
Doens't matter which you configure, as long as its opposite of Telco.
If they are not opposite you will encounter an issue known as glare, where two calls try to grab the same channel simultaneously.

-SD-
 
Thanks to everyone who responded - we're set up OK on the acending/decending sequence. I'm checking into the software release issue posted by SupportDude. Our system is release 7.1, issue C12 and I'm trying to find iss 2.12. Is this a newer issue?



 
If your SP Version ends with C12 ... it is 2.12.
In the Nortel world A=0, B=1, C=2, and so on.

So, the version you have should have corrected your issue.
Maybe you got some bum s/w.

You may need to contact Nortel.

-SD-
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top