PRI & ESS5 3

[rislejay]

I have seen the conflict between the PRI and the ESS5 mentioned in two threads. Can anyone elaborate more on this? I have been struggling with this problem for over a year now with no end in sight. We have had many onsite meetings with the telco and our vendor with no resolution. The lines usually need to be reset first thing in the morning but unplugging the PRI waiting a minute and then plugging it back in. My vendor mention the problem was at the CO and had to do with their switch, a ESS5. What information can you pass on to me so I can pass it on to them?

Thanks.

 

[Norstarguru]

What are the error codes in the network event log under maintenance?

Depending on the telco usually the problem lies in the programming on the 5ess, One setting can throw the whole thing off, You may want to find some one from that bell company that has the same kind of circuit on a 5ess and have them copy the programming from that PRI to your PRI, The network event log will tell you exactly what the problem is.




norstarguru

http://www.1stalliancecom.com

 

[rislejay]

The only codes that show up under the event log are from (un)plugging the PRI, 42-1, 41-1, 44-1. A typical morning consists of checking the link status of the PRI lines. If any of them show as FAR then the PRI is disconnected and reconnected to reset the PRI. If all lines show as far, users are unable to make outbound calls. Inbound calls will come in without a problem. After the inbound call has been disconnected the link status for that line will show as IDLE, clearing out the FAR. So 23 inbound calls coming in at the same time would do the same thing as disconnecting and reconnecting the PRI. Vendor states that the telco runs maintence on the line which causes the problem. Maybe their is something misprogrammed, I'd love to bill them back.

 

[PERRYPJ]

LET ME TRY TO EXPLAIN THIS, THE PROBLEM IS IN THE ESS5 OFFICE. THEY DID A SOFTWARE UPGRADE IN THE CO 1 OR 2 YEARS AGO, THERE IS A PARAMETER, AND I BELEIVE IT'S IN THE ISDN- PRI PARAMETERS IT GOES OUT AND CHECKS THE BCH EVERY NIGHT.
THEY NEED TO DISABLE THE TEST AND PROBLEM GOES AWAY.
IT'S BEEN ABOUT A YEAR SINCE I WROTE ABOUT THIS AND CAN'T REALLY REMEMBER WHAT THE NAME OF THE PARAMETER IS, BUT IF SOMEONE WOULD SAY THE NAME I SURE WOULD REMEMBER QUICK.
I SPENT OVER A WEEK ON THIS TROUBLE WITH WORLDCOM BEFORE WE FOUND IT

OLD ROLMEN WORKING ON NORTELS

 

[PERRYPJ]

I FOUND THE INFO:
Ask the CO if they are running 4ESS, if so have them turn off B-channel services, they call it BCAS.

The setting will cause the lines to go out of service everynight. If an incoming line comes in it will clear the channel. To test reboot the MICS and see if the channels come up.

OLD ROLMEN WORKING ON NORTELS

 

[PERRYPJ]

SHOULD HAVE SAID 5ESS

OLD ROLMEN WORKING ON NORTELS

 

[rislejay]

Thanks PerryPJ, I have a meeting setup for Wed and will pass the info along. I'll keep you updated.

 

[cowenby]

Apparently, the Modular ICS does not support B-channel service messaging. B-channel service messaging should be disabled in the central office when an NI-2 PRI trunk is provisioned for a MICS. This is NOT the default setting in the central office when a PRI is provisioned.

This applied to Nortel DMS-100 central offices, in addition to the 5ESS.

One indicator of this problem is one or more B-channels may show "Far" [end out of service] when you check the Link Status from Maintenance.

 

[rislejay]

I am trying to make this happen at the CO. I have met some resistance from Verizon. Try want to test some other things out first, new line, switch, etc, before they make a software change. Thanks for the info.

 

[cowenby]

Good luck! It took us seven months to resolve all of our issues with the PRI. During that period, we had service failures every five to eight days. Tomorrow will make five weeks that we've gone without service interruption.

The three changes that resolved our service issues were:
1. Changing the protocol to NI-2
2. Turning off B-Channel Service Messaging
3. Changing the destination code for outgoing calls to '9 Any'

 

[rislejay]

Follow up

The problem has been resolved. Verizon changed the standard primary parameter from national to bell core. Which from what I was told is better able to handle what appears to be an internally sourced problem which happens at 12:06 am most nights. They noticed this after a few weeks of watching the pri. Finally resolved after 18 months.