Odd PRI problem on 81c

Odd PRI problem on 81c
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.nortel  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Odd PRI problem on 81c RonB 04-04-2006
Posted by RonB on April 4, 2006, 11:31 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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.

--
RonB
"There's a story there...somewhere"

home networking made easy, greater protection, less stress, introducing nm 5.0, 728x90
Posted by RonB on April 8, 2006, 2:03 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

> 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 Chris Romero on April 10, 2006, 5:03 am
If you were  Registered and logged in, you could reply and use other advanced 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
If you were  Registered and logged in, you could reply and use other advanced 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 ThreadsPosted
problem with NAM vm box June 1, 2006, 10:52 am
Problem. December 21, 2006, 8:07 am
Callpilot Problem March 9, 2005, 11:14 am
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

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map