[Asterisk-Users] Will Echo problems EVER be solved, I'm scared

[Rich Adamson]

> >> >> > Is it practical to 'assume' that in your case mentioned above that
> >> >> > #1 is not going to occur again (since I assume when you say 'line'
> >> >> > you are referring to an outside pstn line), and, #2 is in a mode
> >> >> > of fine-tuning the training when in fact you'd really like it to
> >> >> > start the coarse-training from scratch?
> >> >>
> >> >> Thanks Rich for the comments. Obviously you got my point. And I was
> >> >> hoping
> >> >> that it is possible somehow to do #1 (coarse-training from scratch) 
> >> >> after
> >> >> a
> >> >> PSTN line is transfered to another phone or something very important
> >> >> changes
> >> >> about a call. But considering how complicated a situation this might 
> >> >> be
> >> >> (there is music on hold to say the least, or perhaps the transferee 
> >> >> may
> >> >> reject the call and the call returns to the operator [in which case 
> >> >> you
> >> >> wouldn't want #1], etc.) I guess this is not a simple task. Anyway, 
> >> >> I'll
> >> >> keep on watching for a solution.
> >> >
> >> > The echo canceler preload happens shortly after the analog line is
> >> > seized. Since a call transfer does not open/close the pstn line again,
> >> > its not going to preload again. However, it should not have to anyway
> >> > since there hasn't been any electrical changes there.
> >> >
> >> > What type of phones are you using internal when you're transferring a
> >> > call?
> >>
> >> The internal phones involved were both analog phones, i.e. Zap channels.
> >> This problem happened once in the last 2 days (with KB1), so I'm not too
> >> negative.
> >
> > Are the analog phones connected to a TDM card, channel bank, or what?
> >
> > cvs head or stable & version?
> 
> I have 2x TDM cards (4x FXS + 3x FXO), so all analog phones and pstn lines 
> are connected to TDM cards, Rev E/F.
> 
> Asterisk CVS-HEAD built by root at asterisk on a i686 running Linux on 
> 2005-08-19 22:03:57 UTC
> 
> That's on an Athlon 2000+, with CentOS 4.1, 2.6.11 kernel.
> 
> (I have the monitor recording of that call, and I've listened to it a couple 
> of times. When the caller from pstn is talking to the operator [before 
> transfer] I can't hear echo, but it's a very short converstion, so now I 
> can't be sure %100. But after the transfer I can clearly hear the echo. I 
> should catch another case like this.)
> 
> Thanks for the splitter answer, btw.

I don't use the fxs modules on a TDM card, so all I can do is guess
that the internal call handling (eg, drivers) for the fxs is suspect.

The guess is based on an assumption that *'s echo canceler is involved
with fxs modules since there _is_ a hybrid involved, and, another set
of canceler parameters are involved with the fxo side of the call.
(In effect, two instances of the canceler per fxo->fxs call.)

Since you've mentioned the echo after transfer doesn't happen on a
regular basis, that would suggest the problem is not a coding issue
as that would likely involve echo on every transfer. If its not a coding
issue, then its likely the issue is related to interaction of the two
echo canceler instances.

Might try playing around with the canceler parameters on the fxs channel.
Since the analog fxs phone is always very close physically, maybe play
with the echotraining (echocancel=32, and other echo parameters) to 
see what impact those might have. (In theory, using something like
echotraining=800 on the fxo port and echotraining=200 on the fxs port
might influence the interaction, if that really is the issue.)