Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Re: ascend-users-digest V96 #926
Hi,
Andre Beck <beck@ibh-dd.de> wrote
>
> IMHO that's more than 12 months.
in dubio pro reo (oder so aehnlich) ;)
>
> 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'm not sure whether that's too complicated for Ascend to be
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 know that Christoph Rohlaender was involved on the German part of
the problem but this "feature" seems to be implemented from abroad
without a reality test in Germany :-(
> 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.
At least that's the info you get from the local service. Even if you
use an ISDN analyzer its close to useless to convince a local
technician from the Telekom. Even if *HE* is convinced, how long will
it take for the change to be implemented by Siemens or SEL in the
system software ?
If *YOU* have the Q.931 and can proof the problem to be on the
Telekom side, have you talked to them ? What did they say ?
Previously I thought it would be easier to implement a working fix
for that in the firmware than having the Telekom change their
timing. Meanwhile I came to the conclusion that it's more likely
that the problem is fixed earlier on the Telekom side, even before
Ascend *REALLY* knows what the problem looks like...
>
> > 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).
>
I don't care *HOW* if it's fixed at all in a reasonable time, say:
ho about another 12 months :-(
Bye, Torsten Droste
----------------------------------------------------------
Torsten Droste td@pop-stuttgart.net
Internet PoP Stuttgart IPF.NET phone: +49 711 6574500
INC InterNet Connectivity GmbH fax: +49 711 6574501
Schenkendorfstr. 17 70193 Stuttgart
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>