Has anyone come across this:

DX120 with a PRI that has intermittent all busy or no ring at all for inbound callers. Outbound calls are fine.
This problem started after upgrade to F22/F.07. Tech support had me re-install F22 and install a new F.07 chip. After 6 days, problem started again.

Edit: This system was working fine for 2 years prior to the upgrade.

Thanks.

You might try putting F20 and your old firmware chip back in. I seriously doubt this is the problem though. Did you download the database and upload it when you updated the software? It's possible it's corrupted. Secondly I've never seen a DX PRI work for a few days then fail. I'm a bit more inclined to think something may have happened to the cabinet versus a fault in F22 or the PRI card if in fact it's the DX-120. To date EVERY single PRI issue I've ever seen with the DX-120 has been the LEC except for one cabinet that had a faulty clocking source and another that had a bad memory segment. We have better than 60 PRI installs.

I would go ahead and and put your spare cabinet and PRI card in and see what happens. If it still occurs then you pretty much know where the trouble lies. Check your distributor for PRI card prices. I went ahead and put another six on my shelf.

Yes...I downloaded then uploaded after cold start. I was thinking corrupt database as well, because this was working fine for 2 years. The carrier did do extensive testing for about 4 days and came up clean. On the clocking...the DX is supposed to be the slave, correct?

Unfortunately, I had left the telecom business to take a job offer with a client of mine for about 2 years...I'm now back in telecom but sold off all my spare everything!!

Question...
Could I default the system, upload the database prior to the f22 upgrade, then do the upgrade to f22 while still leaving in the f.07 PRI chip in place? I no linger have the .05 chip. Or, should I just build the database from scratch?

One other item...

When I had originally upgraded the system, it was to f20. But, on the advise from a Vertical tech, I had the installed f.07 chip at that time. I later upgrade to f22.

Reinitialize the system and reprogram. F22 with F07 has been very stable.

Yep...going to stare and compare. Thanks!!

Ok, so that didn't work...hand packed data base, same thing. Now tech support wants me to downgrade to f19 and the f.03 PRI chip and push the old f17 database in. Sounds like throwing darts for a solution.

Question: Would having the co lines Ans. Pos. for the PRI pointing to ext. 101 WHILE using DID's that point to UCD or user ext's cause my problem? It worked fine this way for the first 2 years, but after the upgrade to F22/F07 I get the failure. Could the F22/F07 not like this conflict

Tech support thinks the carriers equipment doesn't like the F07 and/or F22.

I think tech support is nuts. If it worked fine with F20 and F.03 then why do they say F19?

Did you reload F20 with F03 like it was before the problems? If so and it still isn't working then replace the cabinet with a different one with F20 and F03. If it still doesn't work then something changed at the carrier. It is "slightly" possible the cabinet went wacko. I've only seen it once but something happened to clocking on one of my cabinets causing all kinds of erratic operation.

As far as the CO lines pointing to 101 it "might" be possible this is causing an issue. Regardless I would exclusively use the translate table for incoming ringing. It's kind of why it's there.

Frankly with the issues showing up after six days or so I'm leaning to errors on the circuit and not the DX. Have you had the carrier check for slips, CRC errors, etc? Is it a fractional PRI? I've had faulty Adtran or Cisco interfaces cause whacked out problems with the PRI. Is it possible you were on an old school C.O. phone switch like a #5ESS and they switched it over to a soft switch? I've had that happen to me too.

Tough deal to really isolate if you don't have spares.

It was on f17/f.03 when it was stable. I had a problem with the modem not answering when I was told I needed to upgrade to resolve the problem. Now that f17 cpm software is not available, they wanted me to go with f19/f03.

At this point I've not downgraded anything. Only gone from f17/f03 to f20/f07 then f22 only (kept same f07 in PRI) then a reload of f22 and a new f07 chip then cold start and new database...all on the advise of tech support.

Carrier has checked everything. Not a fractional PRI, have a smart jack 6' from my switch into a adtran, then the DX. I've pulled the adtran out and still had the failure.

I did remove the ans. pos. for the PRI trunks yesterday...now we wait.
I'm going to get the carrier involved again and check what they're using on their side.

I agree...a pain without spares.

One other thing...Tech support is now saying the f22/f07 was developed only to address the problem the DX/PRI was having with soft switches. In other words, I really didn't need to upgrade a damn thing in the first place.

You can read info about your circuit with the adtran installed. Any errors and which side they come from!

I'm not at all convinced it's F22/F.07 but go ahead and load F20/F.03. If it still acts up then there's only 2 likely things that it can be, faulty cabinet/PRI card or the LEC.

Did the LEC loop up the smartjack? I've had them tell me there's no errors but when I have them loopback they find issues. Never ever trust anything they say.

Also make sure all of the posts are tight that are holding the CPU, PRI and voice mail cards. Run a ground between the cabinet and the smartjack. Check/replace the data cable between the PRI and smartjack. Make sure this cable isn't near a faulty lamp ballast. Check if the battery backup isn't momentarily switching causing spikes. The DX should be slave, B8ZS, ESF.

Keep us posted.

I don't know if the LEC has looped the smartjack, for sure. If they did, they did this after hours...and, yes, they are notorious for claiming "all good" on their side. I once was arguing (on a Executone) that is was their equipment because I had 2 T1 cards in 2 cabs that I was switching the suspected circuit back and forth and the failure followed the circuit. The LEC tech said they were looping to their SJ just fine...problem was I had the damn thing in my hand, out of the shelf!! Turns out they were testing the wrong circuit.

Next trip there, I'll ground the cab/SJ and replace cables. The UPS is 3 years old now. All posts are tight and cab is grounded well.


Switch has been stable since last Thursday so far.

Oh...and I'll get into the adtran as well...

Thanks for the help.

Pri went down again today. This time the carrier could see the D channel was down and is escalating the ticket to ATT who owns the smart jack. Should have an answer tomorrow as to who dropped the D channel...the DX or ATT.

Keep us updated but by all indications there's a circuit issue.

Tests come back clean on the carrier side. They looped all the way to the CSU. When the PRI went down earlier this week, they seen that the D channel dropped.

Question: The D channel is channel 24, correct? What problems might be caused if users have access to CH.24 of the PRI? If trunk 839 (PRI is 816-839)is in grp 1 and that is the grp the users have for the PRI, is this a problem?

So, the problem narrowed down is that the DX seems to be dropping the D channel.

I did confirm that a #5ESS is the switch in use by CO with no change outs since the circuit was put into service.

Thought I'd found the problem...during the software upgrade, ESF got changed to SF and I didn't catch this. However, last week I changed it to ESF via remote connection and confirmed the change actually took place. System failed the same way again today. Went 6 days with no failure, then "poof". I thought for sure the SF/ESF safu was the culprit but it works/fails in the exact same manner. Carrier was surprised the circuit worked at all with the SF setting.

Purchased a new card today, Vertical warranty is useless...want me to send the card in for repair.

Will update what happens post new PRI card install.

Update...

New card failed as well but this time right away. The circuit was up, no alarms on the card, none reported in PCBA and none on the carriers side and still, calls inbound would get no ring and just sit there without being dropped. Outbound calls worked fine.

Called Tech support, they had no idea so I had them send me F17, I installed it and the F03 PRI chip, installed the original F17 database, then outbound only calls failed with the phone sets reading "yellow alarm". However, no alarms on the card/carrier/PCBA. I installed the F05 chip in the PRI then outbound calls failed with "trk release". I thought this may be the F17/F05 not being compatible so I installed F20 and all works at this point but we have to wait to see if it will again fail.

At this point I think my CPM or cabinet is hosed in some way.

10 days with no failure thus far.

So at this point you're running F20 with the F05 chip?

Justin

Yes. F20 F05 and no failure with the PRI. However, the VM is again not responding randomly. They have to reboot it to get it back online. This problem vertical tech support told me was a hardware failure issue. This 'hardware failure'didn't happen the entire time we were running the F22 F07 combo, but then the switch was being rebooted often (once a week or more)to correct the PRI.

After looking back through my email on this issue, it does appear that the PRI problem started within 2 week after upgrading to the F22/F07. It went over 3 months with no failure when we upgraded software to f20/f07 as per vertical support to correct the VM issue. It was after vertical told me to uprgade the cpm to F22 to further address the VM issue when the PRI first failed.

Have you replaced the dx80.hex file (if it's a 7271C) on the vmail?

As far as I know F20 and F22 are identical except for some minor PRI tweaks. It sounds to me more and more like there's some kind of cabinet issue. There's a chance the cabinet has a bad memory segment or the clocking circuit is faulty.

Yes. I replaced the Hex file when we went to the F22/F07. VM stopped answering the next morning. Vertical support had me remove it (the hex file) and replace the original hex and cited the problem as hardware failure due to a code in the error log.

I thought for sure it was a cabinet problem too. But since the F20/F05 is in it, no failure on the PRI going on the 3rd week now. Before, it wouldn't make it 6 days before failing.

Ok...it's been a year with no PRI issues. The CPM crashed last week and we replaced KSU1 and the PRI card.
Everything came up fine with no problems...until today. Again, calling in we get nothing...no ring...no busy...just dead air. HOWEVER, if I call in and get dead air and make a second call, it rings in fine. If the first channel is busy, the rest work fine.

HELP!!! I don't think I want to waste time calling tech support because last time they did nothing to help.

Card is programmed ESF B8ZF (manual says to keep at SF but I believe the carrier required ESF)

A couple things...
This new system is F22 with 07 on the PRI. The same combination that failed on the old system. I uploaded the saved database from the f20/05 that was stable for the past year.

I have 2 common denominators in this problem with f22/07...
The carrier and the CSU. The carrier is telepacific and the CSU is an adtran ACE.

Adtran claims their equipment can not cause this issue.
Seem obvious at this point something downstream from the DX doesn't like the F22/07...6 days after working fine!!!

new info...
What is causing the failure this time is...

Call to a fax via DID. Fax doesn't answer, call goes to VM. If I press 0 for operator, my call goes to modem or fax tone. Hang up, call back and get dead air...the first channel is now locked up. Reset switch and all is fine.
This time, this is what the issue is as customer complained that fax number was not ringing to fax. I called in last night on the fax line, got VM, hit 0, got fax/modem tone, hung up, called back and got dead air.

Just need to find where the call is going when i press 0 from VM that gives me tone!!

Found the problem...
In a word, HACKED!!

Someone had place a phone number, 91800XXXX in box 888 (my press 0 box)where we had ext. 101. Also, they had created another box (699)with that same number in the same field. When you call the number you get ATT.
Apparently the 9 at the beginning of the number causes the lockup with F22/F07 but no issue with F20/F05. Like I mentioned before, if you pressed 0 from VM you get this DTMF tone (not modem) and then callers would get dead air unless someone was already calling into the PRI, channel 1.

Resetting just the CSU clears the problem for 1 or 2 calls, then it will lockup again. Resetting the KSU clears the problem with no failure after.

Since no complaints about pressing 0 for the operator were ever reported to me or to my customer, I'd never dreamed that pressing 0 has been the trouble all along!!

Interesting. Good job finding that one.

There's a vmail setting that can be changed to fix this but in this case it's a good thing it wasn't set. I've had this happen before on a notification issue and it drove me crazy.

Since this has happened once and you don't know why then I would consider deleting MB 70 or at the very least changing the password to MB 70.

I always implement the setting Bill is mentioning. This was after having a system hacked. From that point forward, every system I worked on got that config entry, disallowing changes to the Transfer To field from the phone. That's the global way to do it. You can also use brackets in any field that has an option to be changed from the phone, to individually prevent a field from being changed from the phone. I prefer the global method for the Transfer To field, though.

Justin