Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Re: ascend-users-digest V96 #749
On Fri, Aug 15, 1997 at 10:20:33AM +0100, Torsten Droste wrote:
> Hi Thomas,
> > No, it's different.
> >
> > The Max calls the Pipeline, the Pipeline "sees" the CLID and _rejects_ the
> > call. The Pipeline then calls the Max.
>
> This is EXACTLY what it is supposed to be. The reality is the
> following: the Pipe50 sends not a "reject" but a "normal clearing"
> cause code. Other cause codes like "bearer service not available" are
> returned by the switch immediately so the problem lies within the
> normal call clearing.
But this _especially_ is a -T-- side bug. Q.931 only allows a slight delay
for _one_ special cause code, "Call Refused", and only in one situation,
on a P-T-MP S0. IMHO Ascend uses "Normal Call Clearing" especially because
"Call Refused" may be delayed (somewhat, maybe up to 8 seconds adding up
all T* from Q.931). But "NCC" can never be delayed as of Q.931. The -T--
has to fix their code. As this works on some switches, it even more is
likely to be a bug.
> We have checked that with the Telekom's ISDN analyzer (I
> think it were various firmware versions 4.6CP9, I11 etc. and 5.0a)
> in November 96/April97. Furthermore, the cause code has to be mapped
> to EDSS1 if one side has 1TR6 which causes additional problems.
I wouldn't think so. There should really be no delay in converting a
cause from one protocol to another. This problem also never existed with
1TR6. They (-T--) simply don't get Q.931/NET3 right, thats all.
> > The problem here: The reject is hold by the german telekom for up to 40
> > seconds.
>
> Not the reject but the normal clearing. You can verify that with
> an ISDN Card and software which is able to send a real reject or
> another cause code. Then the Max get's the response within a few
> (1-3) seconds. Still a delay parameter for the Pipe50 would make
> sense.
Double that (delay parameter). At least in 5.0A you can say that whith
CLID mismatches, the Ascend should use a "User Busy" cause. Dunno whether
that also plugs in for CLID callback.
> see my previous message for the workaround.
Which works but is - uh - ugly. Especially if the far end customer for
some reason switches off Callback...
> Greetings from the wild south :-)
Dito from the wild east ;->
--
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: <http://www.nealis.net/ascend/faq>
References: