Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Re: ascend-users-digest V96 #920
On Thu, Dec 04, 1997 at 03:09:39PM +0100, Torsten Droste wrote:
> Kevin,
> >
> > I would suggest you investigate this further, as we have seen this also
> > in Germany where the called-party disconnects, but the disconnect is NOT
> > sent to the calling end for a few seconds. The MAX did not know the remote
> > end had disconnected.
> >
> > >Is there any way to make the MAX accept a callback call although it is
> > >still actively requesting the callback? - or is there a way to make the
> > >MAX disconnect a callback request quicker?
> >
>
> Sure there is way but Ascend is not able to implement this feature
> for 12 month now!
;->
IMHO that's more than 12 months.
> if the MAX dials out for a predetermined time (a.k.a. radius
> Ascend-Callback-Duration or something like that), e.g. 3
> seconds, that would be enough to signal the number on the d-channel.
> It doesn't matter WHY there is no callback, only that ther IS NO
> callback at all. Therefore the disconnect cause is NOT needed and
> it's not necessary to wait for it before releasing the route which
> causes the security error.
Another option I have mentioned here several times would be to simply
give ExpCallback aka Callback-Expected-Yes a real meaning: If an out-
going call is made with Callback-Expected-Yes then it is no intention
to build a link and thus doesn't need to allocate the route in the
first place. If a call is Callback-Expected-Yes than another incoming
call on the same profile is NO call collision but instead could be used
to drop the outgoing call and then has to be answered. The information
is already there - it just has to be used more educated than "uuh - we
won't call out again for the next 90 seconds".
> > I don't think it's the MAX "holding on" to the call - but the call disconnect
> > message is being delayed on it's way to the MAX.
>
> Exactly. As Ascend knows that, why is it so difficult to get the
> above fix implemented ?
My impression is that Ascend can develop some selective ignorance to
certain problems. Sometimes this finally resolves (Ho Ho Ho - Leased/Leased
is there in 6.0!) and sometimes not. We hoped the callback problem
would resolve in 4.6Csomething when the mysterious ExpCallback made
it into the code - but what ExpCallback really does shaked us.
> > I guess while we investigate this, you may want to do that. Unless the
> > authenticate trick works....I'll check into it more here.
> >
> there is nothing to investigate further. The problem is clear,
> e.g. German Telekom claims they stay with the standard for delaying
> the disconnect cause. So the only way to get this problem fixed is
> the above mentioned.
I would doubt that. Q.931 specifies ONE case where a disconnect can
be delayed: "Call Refused" aka 21 can be delayed up to 7 seconds or
such on a P-T-MP S0 in order for other devices to still grap the call.
There is no reason, however, why "Normal Call Clearing" should be
delayed as it is more like "I take it and immediately drop it" instead
of "I won't answer this". To be silent of the delays we have seen in
reality which were far beyond 7 s. There _is_ something wrong there.
> Come on, it's a few minutes work to implement the timeout value
> for an outgoing call choosable by a parameter.
Or give ExpCallback a more educated meaning. We are using the wrong-
IP-in-outgoing-profile-hack to trick the Max but maybe this tricking
is a source of other problems (I could imagine memory leaks to build
up on it).
--
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: