[Asterisk-Users] Echo on a PRI

[Rich Adamson]

> On Tuesday 20 July 2004 09:22, Ryan Thrash wrote:
> > Oops. I need to correct my last post: I don't have the PBX in the mix.
> > My config is dual Xeon 2.4s, 1GB RAM, HW SATA RAID, SuperMicro
> > X5DAL-TG2 motherboard connected to:
> >
> > Telco - PRI (T100P) - Asterisk - SIP Phones (Budgetones 102s/Snom 200)
> >
> > The premise is still the same though: echo present despite our digital
> > PRI that *should* make this impossible. It's usually only echo on our
> > side when calling out as has been discussed here previously ad nauseum
> > with no one being able to really figure out its source. I wish I knew
> > where to really start poking around to try to help get to the bottom of
> > this.
> 
> No, the PRI does NOT make echo impossible.  It makes it highly unlikely that 
> YOU will generate echo.  You never hear echo YOU generate; you hear the echo 
> being generated on the other side.

Unless I've totally misunderstood the double negatives in that statement,
I don't believe your statement is accurate at all.

The echo problem that most of us have (or had) does result from audio
initiated by sip phones (etc) passing out through any number of zap
oriented cards/adapters to the pstn (regardless of who the pstn provider 
happens to be).

The technical issue seems to be oriented around...
 a. rtp packet arrives at asterisk via the LAN (as an example only),
 b. asterisk queues the rtp packet/bytes for transmission via a zap channel,
 c. the system sends pkts/bytes to zap card, and for _lots_ of 
    different reasons, some of the audio (pkts/bytes) are reflected
    back towards the inbound side of the card (to asterisk code) via
    the PCI and interrupt structure,
 d. the current echo canceler removes that reflection **if** the
    pkts/bytes arrive (in * code) within a certain amount of time,
 e. if the reflection falls outside the current canceler's limits, or
    if some other audio interference is involved, or if an interrupt 
    or two is missed, the reflected audio is not removed by the 
    current canceler (as it falls outside it's limits) and we hear
    echo. 

The echotraining=800 enhancement represents one step towards reducing
critical timing part of pulsing the zap channel and "pre-loading"
the canceler with something reasonable. That, in effect, removed
the 5-to-20 second training period for the canceler. It had nothing 
to do with addressing the limits or thresholds of the canceler itself.

Regardless of whether one uses a zap driven PRI, T1, or analog line,
there is reflected energy (eg, audio) that needs to be removed by
the echo canceler. The "amount" of reflected energy varys by type
of facility (eg, PRI vs analog line), by call destination, the 
efficiency of any hybrid involved (if any), etc, but its still 
there in all cases, period.

What remains for the current echo issues seem to boil down to two
somewhat unrelated issues (there might be more):
 a. internal system delays possibly resulting from interrupt service
    latency, internal PCI structure, etc. (Those systems with this
    issue seem to have some degree of echo on all calls. Swapping
    motherboards is known to impact this one to some degree.)
 b. echo on "certain" zap calls where it appears the reflected energy
    falls outside the limits of the current canceler. (Those are
    likely to relate to significant time delays in the reflected
    energy and _might_ be related to the type of facilities used
    within the carrier's network. Likely in the Sprint case noted.)

Whether one has echo with NuFone calls or not is totally irrelevant 
as those calls are not sent through zap channels, and are not 
subjected to the same echo canceler issues noted above.

Trying to identify _factually_ what the various limits happen to be
with interrupt latency (etc), reflected energy from both local and
outside sources is not an trevial task. Changing the echo canceler
to support whatever those limits happen to be is likely to be far
more difficult.

As Steve Underwood noted earlier, one of the only ways to identify
the issues in (a) is to write a test application that sends data
out through the zap card, loop that data back into the receive side,
and measure the delays (and variation in delay) assoicated with
that path. There could be multiple issues uncovered, and some are
likely to be system dependent.

We'd all like to hope that changes to address (a) would be sufficient
to also address the issues in (b). We'll have to wait and see.

Rich