asterisk users - Dec 2005 - E1 Echo (was: Small explanation of txgain rxgain statement please)

On 12/15/05, Rich Adamson <radamson@routers.com>
wrote:
>
> > I was just looking at:
> >
>
http://www.asteriskdocs.org/modules/tinycontent/content/docbook/current/docs-html/x1695.
> html
> > regarding echo canceller tuning, and I noticed the statement
> >
> > "Most people find that they need an rxgain level around 8.0 to
have
> > good echo cancellation. The txgain setting varies from installation to
> > installation."
> >
> > Which feels a bit wrong :) Could someone explain why increasing the
> > gain on the inbound zap leg (rxgain) would improve echo cancellation?
> > Of have I misunderstood the roles and meanings of rxgain and txgain?
>
[snip]

Many thanks for clearing that up for me :) the largest part of my
misunderstanding was caused by not noticing that that article was
referring to the tuning of an "FXO" line. I am in fact trying to find
information on the tuning of an E1 to reduce echo. (Doh!)

In theory of course an E1 should work with rxgain=0.0, txgain=0.0
(assuming there is no digital messing going on in the network) and the
echo canceller should have a relatively easy job of cancelling echo
given that the large majority of the UK phone network is digital, and
only the last leg at the far end is usually analogue.

I am running Asterisk 1.0.9, and have backported the KB1 canceller
into Zaptel 1.0.9.2, which does not seem to have caused any problems.
Nor has it really caused any improvement though :)

I am beginning to wonder whether what echo IS heard is being caused by
packetisation delays "in the network" - The default tap length is 128,
or I believe 16ms. If something in the PSTN causes a delay more than
that length (no idea what might cause that) then echo would still be
heard.

Does anyone have any experience in this area? Any ideas? How "heavy
handed" would it be to increase the tap length to 256? I have not seen
anyone suggest that this might be a good idea.

Thanks,
Steve

> > > I was just looking at:
> > >
> > 
http://www.asteriskdocs.org/modules/tinycontent/content/docbook/current/docs-html/x1695.
> > html
> > > regarding echo canceller tuning, and I noticed the statement
> > >
> > > "Most people find that they need an rxgain level around 8.0
to have
> > > good echo cancellation. The txgain setting varies from
installation to
> > > installation."
> > >
> > > Which feels a bit wrong :) Could someone explain why increasing
the
> > > gain on the inbound zap leg (rxgain) would improve echo
cancellation?
> > > Of have I misunderstood the roles and meanings of rxgain and
txgain?
> >
> [snip]
> 
> Many thanks for clearing that up for me :) the largest part of my
> misunderstanding was caused by not noticing that that article was
> referring to the tuning of an "FXO" line. I am in fact trying to
find
> information on the tuning of an E1 to reduce echo. (Doh!)
> 
> In theory of course an E1 should work with rxgain=0.0, txgain=0.0
> (assuming there is no digital messing going on in the network) and the
> echo canceller should have a relatively easy job of cancelling echo
> given that the large majority of the UK phone network is digital, and
> only the last leg at the far end is usually analogue.
That last leg "is" usually part of the problem since there is going to
be a hybrid conversion.
> I am running Asterisk 1.0.9, and have backported the KB1 canceller
> into Zaptel 1.0.9.2, which does not seem to have caused any problems.
> Nor has it really caused any improvement though :)
The KB1 canceller improves echo, but it appears as though it achieved better
results by forcing half-duplex communications. From a pure non-technical
user perspective, the quality of a telephone conversation has been lowered
simply because humans are use to communicating in full duplex mode.
 
> I am beginning to wonder whether what echo IS heard is being caused by
> packetisation delays "in the network" - The default tap length is
128,
> or I believe 16ms. If something in the PSTN causes a delay more than
> that length (no idea what might cause that) then echo would still be
> heard.
Certainly not hard to change the tap length and eval it.
 
> Does anyone have any experience in this area? Any ideas? How "heavy
> handed" would it be to increase the tap length to 256? I have not seen
> anyone suggest that this might be a good idea.

Hi,

Rich Adamson wrote:
>>I am beginning to wonder whether what echo IS heard is being caused by
>>packetisation delays "in the network" - The default tap length
is 128,
>>or I believe 16ms. If something in the PSTN causes a delay more than
>>that length (no idea what might cause that) then echo would still be
>>heard.
We have found that a relatively innocent change by the local incumbent 
operator has forced us to modify our pstn gateways to change from 128 
taps to 256 taps. Since th
>>Does anyone have any experience in this area? Any ideas? How "heavy
>>handed" would it be to increase the tap length to 256? I have not
seen
>>anyone suggest that this might be a good idea.
There have been a few issues especially related to the echotraining 
section (which can go boo-boo on E1 lines because the audio path is not 
always entirely complete when zaptel expects it to). If you make sure 
you are on recent zaptel EC standards you can up to 256 taps. There will 
be a minor residue that needs work, but it will allow a lot of room to 
decrease the loss-plan you may be using now.

Florian.

> >>I am beginning to wonder whether what echo IS heard is being caused
by
> >>packetisation delays "in the network" - The default tap
length is 128,
> >>or I believe 16ms. If something in the PSTN causes a delay more
than
> >>that length (no idea what might cause that) then echo would still
be
> >>heard.
> 
> We have found that a relatively innocent change by the local incumbent 
> operator has forced us to modify our pstn gateways to change from 128 
> taps to 256 taps. 
What type of a change did they make?

On Friday 16 December 2005 09:02, Florian Overkamp
wrote:
> Well, the problem is the difference between keeping under 16ms and
> sliding _just_ over limit to 18ms would make the effect audible almost
> immediately. We used the sangoma echospike tools to measure the delay
> and adjusted our taps accordingly.
Sangoma echospike tools?  Please elaborate!

-A.