PRI over T1 network

[fsoz]

I have a point to point T1 that I run PRI using switch types, Merlin network to Merlin PBX. It works well most of the time, but then I get DS1 Slip alarms, DS1 loss of signal alarms, Yellow alarms, Blue alarms, then it goes into either PRI D-Channel inop, or Pri service audit timeout. The only way to get it back up is to go onsite and reboot. It's usally the PBX end reboot that brings it back up, but sometimes it takes a network end reboot. The carrier says they can't find any problems, of course it doesn't act up when they monitor it. I also run 4 channels of data over the same T1, and that always comes back up by itself, which makes the customer think it's the Magix system. Avaya says to switch to T1 instead of using PRI, but customer would lose display info. Any ideas?

 

[itpphoneguy]

Hi fsoz,
Where do you get your system clock sync from? If you have a PRI from Bell for your incoming lines, then sync off that. This really sounds like you are losing the clock and the system is switching to a back up clock source. The remote Magix (?) should then sync off your point to point PRI. That should keep them all locked up.
Another thought. Find out where the greatest jitter rate is on the clock. Your may have a flakey PRI card. That wouldn't be the first time.
-Chris

 

[fsoz]

The main system gets it's sync from a two-way T1 in slot 05. That is set to Primary- loop. The point to point is in slot 06, and that is set to local. The far end is set to loop. Where do you get the jitter rate reading? I still suspect the point to point is flakey. I've been onsite when it's down, and the smartjack has no lights on, or they are showing error. Then it goes away, and I can restart to resync

 

[Pepperz]

Suspect the wiring / point to point circuit. If no lights are on in the NIU display, then it's broke. Your synching is set up properly, and alarms are then solely hardware related. So, you need to verify T-1 cards / CSU's / Cabling out to the NIU, and have the lec verify the Point to point. See if they can "loop up" to both of your CSU's for awhile, and verify that it is running clean. This requires a downed circuit, so plan accordingly. From your description, it really sounds like a T-1 issue, but proving it takes a lot of persistence. TipHelp@charter.net

 

[pabell]

If you are losing the LED indicators on the NIU from the carrier its their problem ...wiring possible bad pair or
bad card issue .....you should always get a STEADY
Green LED on LP1 ,LP2 if 4 wire circuit or just
LP if 2 wire HDSL-R Card pairgain , Adtarn

DS1 Led on when it sees your equipment

Amber led for B8ZS ,ESF (Frame , Signal)
Green Led AMI , D4 (Frame , Signal)

They may see no errors if they have not run to a loop
they would never see there TRANSMIT your RECEIVE pair
unless they run to a loop or have someone onsite
running head to head with a T-Berd tester looking back

They also may be able to log into the "local" NIU and
pull the error history

If they do loop up and run test have do a "stress"
test on the pipe ...if possible looking bothe direstions

Pabell

 

[jeepguy267]

I had a similar issue that escalated to a totaly down point to point. The end result was a failing smartjack that eventually died. Even once dead, telco could loop TO the smartjack, but not PAST it. It took a lot of convincing to get them on site and then replace the smartjack. The issue immediately went away, but they still would not admit it was them ("smartjack replaced per customer request, no trouble found&quot....these are not nice people. Lesson is have them loop to the csu not just the smartjack.