Odd PRI problem on 81c
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by RonB on April 4, 2006, 11:31 pm
Please log in for more thread options their PRI circuits (all in the same group) are showing "FE DSBL" on a few of their channels -- one loop *had* quite a few reporting FE DSBL, but Verizon has cleared most of that circuit while testing. In most of the loops it only effects the first channel. What's really odd is that these channels are working (they have no problems with dropped calls etc.). When I STAT the channels they show IDLE. When I direct access them with a maintenance set, I get dial tone and I can call out. When they're busy, I can TRAD them and get the call record and they show BUSY when STATed. So the problem seems to be a bogus error report. Verizon Core Group also sees an FE DSBL (or equivalent report) from their side, but they also note that the channels are working. I think the CO switch is a Lucent -- but, so far, no hard confirmation. They've got the D channels set to NI2, but CO_TYPE is set to STD. Our in-house engineer thinks that this should probably be set to ATT instead *if* the CO switch is a Lucent, but he's reluctant to screw around with a switch that is working, especially since it's scheduled to go down in a couple weeks for... some kind of mainenance... I wasn't told why exactly. The PRIs do come through CSUs and this is Rel 4. The switch was installed in November and no one noticed this problem until a couple weeks ago -- but that doesn't necessarily mean the problem didn't exist from the start. The onsite tech just got back from school and was experimenting with some of the STAT commands that he had learned there. At any rate, has anyone ever heard of this problem? It's the first time I've ever seen something like this. Thanks for any ideas. -- RonB "There's a story there...somewhere" | ||||||||||||||||
|
Posted by RonB on April 8, 2006, 2:03 pm
Please log in for more thread options Problem solved. Bell Atlantic (aka Verizon Core) hadn't turned the B-Channel Messaging Service on. Once they added the feature to the PRIs everything cleared up in a short time (and they could actually see the status of the B-Channels where, before, everything looked fine to them). They said that they had had this problem before with Nortel Option switches. It took a while to get to someone who would actually listen -- several open tickets -- but once it finally got to the right tech it was easy. -- RonB "There's a story there...somewhere" | ||||||||||||||||
|
Posted by Chris Romero on April 10, 2006, 5:03 am
Please log in for more thread options Don't feel alone. I once had a failure of a DMS100 card in a Bell South
C.O. in Raleigh. Took me more than three weeks to get them to replace the card. I even had a T1 test set and two site visits from Bell (gone) South techs. Real PIA. I don't doubt the similar things happening in other areas The customer is sometimes insane, but you can always count on a L.E.C. to be obstinate and superior! -- Sincerely, Chris cromero at romero dot org >
>> I was sent out to a site where they've recently noticed that six of
>> their PRI circuits (all in the same group) are showing "FE DSBL" on a >> few of their channels -- one loop *had* quite a few reporting FE >> DSBL, but Verizon has cleared most of that circuit while testing. In >> most of the loops it only effects the first channel. What's really >> odd is that these channels are working (they have no problems with >> dropped calls etc.). When I STAT the channels they show IDLE. When I >> direct access them with a maintenance set, I get dial tone and I can >> call out. When they're busy, I can TRAD them and get the call record >> and they show BUSY when STATed. So the problem seems to be a bogus >> error report. Verizon Core Group also sees an FE DSBL (or equivalent >> report) from their side, but they also note that the channels are >> working. >> >> I think the CO switch is a Lucent -- but, so far, no hard >> confirmation. They've got the D channels set to NI2, but CO_TYPE is >> set to STD. Our in-house engineer thinks that this should probably be >> set to ATT instead *if* the CO switch is a Lucent, but he's reluctant >> to screw around with a switch that is working, especially since it's >> scheduled to go down in a couple weeks for... some kind of >> mainenance... I wasn't told why exactly. The PRIs do come through >> CSUs and this is Rel 4. The switch was installed in November and no >> one noticed this problem until a couple weeks ago -- but that doesn't >> necessarily mean the problem didn't exist from the start. The onsite >> tech just got back from school and was experimenting with some of the >> STAT commands that he had learned there. >> >> At any rate, has anyone ever heard of this problem? It's the first >> time I've ever seen something like this. Thanks for any ideas. >
> Problem solved. Bell Atlantic (aka Verizon Core) hadn't turned the > B-Channel Messaging Service on. Once they added the feature to the PRIs > everything cleared up in a short time (and they could actually see the > status of the B-Channels where, before, everything looked fine to > them). They said that they had had this problem before with Nortel > Option switches. It took a while to get to someone who would actually > listen -- several open tickets -- but once it finally got to the right > tech it was easy. > > -- > RonB > "There's a story there...somewhere" | ||||||||||||||||
|
Posted by RonB on April 10, 2006, 6:24 pm
Please log in for more thread options On Mon 10 Apr 2006 05:03:52a, "Chris Romero"
> Don't feel alone. I once had a failure of a DMS100 card in a Bell
> South C.O. in Raleigh. Took me more than three weeks to get them to > replace the card. I even had a T1 test set and two site visits > from Bell (gone) South techs. Real PIA. > > I don't doubt the similar things happening in other areas > > The customer is sometimes insane, but you can always count on a > L.E.C. to be obstinate and superior! Oh yeah. This is not my first experience with banging my head against the wall when dealing with a L.E.C. SBC and (the old) GTE have also provided similar frustrating experiences. "Nothing wrong on my end..." "Can you check anyhow?" "No reason to." "Well the PRI is going down for some reason." "Okay... Let me conference in the tech at the CO. I'm sure it's not our problem." (I'm not sure if he said "CO".) "Hey, Joe, can you check the logs on circuit xxxxxxx?" "Problems on Friday... and Wednesday." "Well, Joe's showing that there were slight interuptions... but only for a couple seconds." "That's all it takes to disable the PRI." "The times match, but I can't believe that would be the problem." "Believe me it can be..." "I'll send this on a backup circuit, but I'm sure it won't clear it." We had had another tech fighting this for six months, the problem was intermittent, almost every Friday afternoon. I got there, turned the counters way up so the slips wouldn't take down the loop, and then got ping ponged back and forth between SBC's circuit side and pipe side for about a day. I finally got a lady on the circuit side to conference me with the pipe side -- and that's where the conversation above (badly remembered) occurred. My brother had a much worse problem with SBC, with similar result, a conference to the CO and... "Wait a minute, this circuit's reversed and, this one is not even punched down." My brother had spent a week trying to get the PRIs ready for the cut, and being assured over and over that everything had been thoroughly tested from CO to CSU and that the problem was on our side. If only company had provided a T-Bird. I don't really blame Verizon Core for this. Supposedly this is a feature you have to order -- even though it is what's required to make a Nortel work with their NI2 settings. Oh well. It wouldn't be fun otherwise. -- RonB "There's a story there...somewhere" | ||||||||||||||||
| Similar Threads | Posted |
| Odd PRI problem on 81c | April 4, 2006, 11:31 pm |
| problem with NAM vm box | June 1, 2006, 10:52 am |
| Problem. | December 21, 2006, 8:07 am |
| Callpilot Problem | March 9, 2005, 2:14 pm |
| Interesting problem | August 31, 2005, 1:02 pm |
| MICS 7.0 and PRI problem | October 29, 2005, 2:48 am |
| Contivity 221 problem | March 1, 2006, 7:45 pm |
| Found the problem | April 18, 2006, 10:22 pm |
| Problem with QoS on 5520 using EPM | November 17, 2006, 3:02 pm |
| NAM 4 interesting problem | July 25, 2007, 4:43 pm |
| Problem with DN 88XX through ACD | August 14, 2007, 9:49 am |
| Re: Congress IS the problem | June 29, 2008, 11:46 am |
| Callpilot Outbound Fax Problem | February 11, 2005, 9:26 am |
| Nortel NT voicemail problem | March 28, 2005, 12:05 pm |
| Alteon AD4 configuration problem | September 21, 2005, 3:38 pm |
> their PRI circuits (all in the same group) are showing "FE DSBL" on a
> few of their channels -- one loop *had* quite a few reporting FE
> DSBL, but Verizon has cleared most of that circuit while testing. In
> most of the loops it only effects the first channel. What's really
> odd is that these channels are working (they have no problems with
> dropped calls etc.). When I STAT the channels they show IDLE. When I
> direct access them with a maintenance set, I get dial tone and I can
> call out. When they're busy, I can TRAD them and get the call record
> and they show BUSY when STATed. So the problem seems to be a bogus
> error report. Verizon Core Group also sees an FE DSBL (or equivalent
> report) from their side, but they also note that the channels are
> working.
>
> I think the CO switch is a Lucent -- but, so far, no hard
> confirmation. They've got the D channels set to NI2, but CO_TYPE is
> set to STD. Our in-house engineer thinks that this should probably be
> set to ATT instead *if* the CO switch is a Lucent, but he's reluctant
> to screw around with a switch that is working, especially since it's
> scheduled to go down in a couple weeks for... some kind of
> mainenance... I wasn't told why exactly. The PRIs do come through
> CSUs and this is Rel 4. The switch was installed in November and no
> one noticed this problem until a couple weeks ago -- but that doesn't
> necessarily mean the problem didn't exist from the start. The onsite
> tech just got back from school and was experimenting with some of the
> STAT commands that he had learned there.
>
> At any rate, has anyone ever heard of this problem? It's the first
> time I've ever seen something like this. Thanks for any ideas.