I would say
victims[2554] += 3;
as we have noticed this problem on at least 3 customer machines in-
cluding our own ones. The bad thing is, we are 90% ISDN and give the
modem pool just for completeness. But following the upgrade path to
get the modem pool working just remotely correct, we got a defective
ISDN call handling now. What to do ? I'll likely go down to p13 and
tell the modem users they have a problem - don't I ?
Here is a D Channel trace of what happens when the problem strikes:
RCV:
NL: <proto DSS1> <callref caller 04ec> <msgtype SETUP>
<Bearer Capability, cap Unrestricted digital, mode circuit, rate 64 kbps>
<Channel ident, PRI/other, exclusive, B channel units, channel #08>
<Calling party number, type National, plan ISDN (E.164), pres allowed, scree
n user+passed, # 35205XXXXXX
<Called party number, type Subscriber, plan ISDN (E.164), # 47XXXXX
RCV:
NL: <proto DSS1> <callref caller 04ec> <msgtype SETUP>
<Bearer Capability, cap Unrestricted digital, mode circuit, rate 64 kbps>
<Channel ident, PRI/other, exclusive, B channel units, channel #08>
<Calling party number, type National, plan ISDN (E.164), pres allowed, screen user+passed, # 35205XXXXXX
<Called party number, type Subscriber, plan ISDN (E.164), # 47XXXXX
RCV:
NL: <proto DSS1> <callref caller 04ec> <msgtype DISCONNECT>
<Cause, loc LN, code 66 (102)>
XMIT:
NL: <proto DSS1> <callref callee 04ec> <msgtype RELEASE COMPLETE>
<Cause, loc U, code 51 (81)>
Interpretation:
The MAX receives a SETUP for an incoming call. It doesn't even remotely
try to process it. After the timeout, the network sends the SETUP again.
Doesn't seem to bother the MAX, either. Now after the second timeout,
the network disconnects the call, sending a Cause Code 102 (Timer expiry)
issued from the LN (local network). Now the MAX acks this DISCONNECT with
a RELEASE COMPLETE, telling the network that it would never before have
heard of this call (cause 81 means "Invalid Call reference").
Is this TR#2554 ? If yes, please add 3 to the victims list and increase
the priority, because this bug _kills_ us. We've lost nearly a full
weekend now for this. And BTW, when the max stops processing calls, it
is no longer just a HDLC problem. It answers _no_ calls anymore, also
analog calls are dropped.
Andre.
--
Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>>
</PRE>
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<HR>
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg09380.html">Re: (ASCEND) Hash code redux</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg09378.html">(ASCEND) P130 Config Problems</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg09430.html">Re: (ASCEND) P130 Config Problems</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg09382.html">(ASCEND) Ascend picks themselves up and brush off... (fwd)</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="mail26.html#09381"><STRONG>Main</STRONG></A></LI>
<LI><A HREF="thrd192.html#09381"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</BODY>
</HTML>