On 12/15/05, Colin Anderson [EMAIL PROTECTED] wrote:
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.
On my PRI, 256 made things bad, super echo-y. Moving
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
Rich Adamson wrote:
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?
Although it's a bit unclear how things evolved exactly (since no-one
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?
Although it's a bit unclear how things evolved exactly (since no-one
ever tells
On Friday 16 December 2005 08:12, Florian Overkamp wrote:
Although it's a bit unclear how things evolved exactly (since no-one
ever tells us), a number of interconnection points throughout the
country were consolidated, significantly increasing the chance that
delay exceeded 128 taps.
I need
Andrew Kohlsmith wrote:
On Friday 16 December 2005 08:12, Florian Overkamp wrote:
Although it's a bit unclear how things evolved exactly (since no-one
ever tells us), a number of interconnection points throughout the
country were consolidated, significantly increasing the chance that
delay
Rich Adamson wrote:
Strange... I would never had expected consolidation to have that kind
of impact. It almost sounds like they have something in the E1 data stream
that buffers (and delays) content, maybe decoding and re-encoding in some
fashion.
Well, the problem is the difference between
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
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!
Hi Rich,
Rich Adamson wrote:
Sangoma echospike tools? Please elaborate!
See sangoma's -users posting from Dec 13th, which I quote:
I just wanted to let you know that we do provide a tool to debug echo.
We send a unit impulse and record the Finite Impulse Response (FIR) so it
can be
On 12/15/05, Rich Adamson [EMAIL PROTECTED] 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
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
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.
On my PRI, 256 made things bad, super echo-y. Moving back to 128 works good
99% of the time, for me.
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
14 matches
Mail list logo
