Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(ASCEND) The Continuing Saga Of The Inexplicable Fast Busies

I have been conducting some (relatively) extensive tests involving the
"inexplicable fast busy" issue with the Max 2000 and 4000.  Using PRI on a
Max 2000, in this case.  I get the PRI from a CLEC, ICG in fact, whereas
all the voice phones go through US West.

A little background: Sometimes users get a fast busy signal trying to dial
into the Max, even though there are still lines and modems available. 
Sometimes even if ALL the lines are available. :) 

When the "fast busy" problem is taking place, the calls never show up as
incoming calls in the 00-200 status window.  I am not familiar with the
appropriate debugging commands to get any more detailed information than
that about the ISDN system.

A reboot has always cleared the "fast busy" condition, for most users
anyway.

Here is what I have determined.  Some of the results surprised me.  They
might surprise you too, depending.  I've been using a 7.5 dB buildout
based purely on noticing that, on that setting, the line comes up the
fastest after a reboot.  All the buildout values seem to work more or less
the same besides this.  The telco was unable to give me even an
approximation of the line length, so I couldn't calculate the "right"
value.  (Apparently CLEC does not stand for "Competent Local Exchange
Carrier") :)

Supposedly, the switch on the other end is a 5ESS switch (which I believe
should be set as an AT&T type).  I found that the service works
(apparently) equally well whether the switch type is set to AT&T or NI-2. 
It specifically does not work if you set it to NTI, but instead produces
"all circuits busy". 

This surprised me.  Perhaps it shouldn't have.  I've never really done
such "experimental" work on a PRI before.  I wonder if the two systems are
actually "mostly" compatible and work using each other's settings only
under certain circumstances?  Perhaps the switch is actually compatible
with both standards?  Nevertheless, it surprises me to discover it works
at all this way. 

Historically, I have received reports of the system flaking out, and when
it was flaked out, it would pretty much BE flaked out.  Now I hear from
one user (fortunately a clueful one) that the service gives him busy
signals about 25% of the time at all times, even if it is not officially
"flaked out."  This does not particularly surprise me, but leads me to
think the problem might actually be with the telco.  In his case, even
immediately after a reboot he would get the intermittent fast busies.

The fast busies seem to come in "streaks" for him.  I had him dial the
number over and over again and it seems that he will get through
consistently for about a minute, then busy consistently for a while, then
alternate back and forth.

When I set the switch to NI-2 mode, there was no particular difference. 
However, on a lark (and thinking back to someone who said it could be a
timing issue between the Max and the telco) I set "clock source" to No
(whereas before it had always been set to yes) and, to my astonishment,
the line continued to work.  This struck me odd, but then I figured that
the switch might have an auto-sensing facility in place.  Still, it struck
me odd that it would work at all considering that I had both switch type
and clock source set to the "wrong" values.

What surprised me even more was that with clock source set to "No" and
switch type set to NI-2, my user gets the fast busy only about 15-20% of
the time now, instead of 50% as before.  Frankly I am amazed.  But my
sensitivity to amazement is a bit dulled by now. :)

He also gets the fast busy during the time that the line is marked as
disabled, or while the Max is rebooting.  This leads me to strongly
believe that the telco is not completely innocent in this whole mess.  I
was never able to get him to get a "circuits busy" or other such message.

In any case, during the entire time, I was able to call the Max fine using
both the phone in my office (regular voice analog type) and my cellular
phone (VoiceStream PCS type).

An interesting side note, this particular user often remains connected to
the system for days at a time.  It doesn't bother me much because I have
plenty of spare lines.  But I wonder if that might have something to do
with the whole thing.

I will see how long it takes before the system wigs out in general again.
At least I appear to have reduced the severity of the problem.  (which is
better than nothing, but not what I was looking for).

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
Follow-Ups: