[Asterisk-Users] Echo on a PRI

[Deon Rodden]

I installed a server in Australia with a Wildcard X100P in it. From my
server in the U.S, I pushed a call via IAX to the server in Australia which
then pushed it out that card. Severe echo, only I could hear it though. The
remote side heard nothing. Definately been reading up on this echoing issue.
I thought the main reason was latency, and my ping to that server in
Australia reveals 200ms response times.

However, they have a HT286 Converter there in Australia on the same
connection, and it connects to my Asterisk server here in the US via SIP and
it places calls all day long with no problems.

I'm going to try more testing, like connecting a HT286 here in the U.S
straight to their Asterisk server there and trying to make local calls. Will
then try Asterisk to Asterisk communication via SIP instead of IAX.


----- Original Message ----- 
From: "Rich Adamson" <radamson at routers.com>
To: <asterisk-users at lists.digium.com>
Sent: Tuesday, July 20, 2004 10:17 AM
Subject: RE: [Asterisk-Users] Echo on a PRI


> > On the subject of echo on a PRI, I too get this, but only when calling
> > people in certain rate centers.  Calls within my LATA (primarily VZ) are
> > completely free of echo.  Calls to a neighboring LATA (all Sprint) have
echo
> > on almost every rate center.
> >
> > I wish I knew more about this so I could rip Sprint a new one and tell
them
> > to fix their trunking, but...
>
> Troy,
>
> Given the reseach that is currently going on, etc, I would not bet
> any more then a cup of coffee that Sprint (or any other carrier) has
> an echo problem right now. There _appears_ to be an issue with the
> echo cancellation routines in asterisk that is impacting more then
> a couple of implementations.
>
> The research to date suggests the current echo canceler works well
> in some cases, and not so well in other cases. In other words, there
> are a certain set of undocumented/unknown conditions (and/or PC systems)
> that fall within the thresholds of the current canceler that work,
> and other conditions (and PC systems) that fall outside the limits
> of the canceler that are less then acceptable. The limits and thresholds
> are _not_ black & white and may end up being one of the more difficult
> problems to solve within asterisk. (E.g, it's entirely possible that
> your calls via Sprint fall outside the limits of *'s canceler.)
>
> As you've probably seen earlier on this list, there is a high
> probability that internal system issues (eg, interrupt servicing
> latency, possibly PCI bus issues, etc) that are impacting this in
> _some_ specific cases. In some cases, swapping the motherboard did
> in fact impact the cancellation quality. However, be very carefull
> not to read anything more into that at this time.
>
> There is no one at this time that knows "factually" what those limits,
> thresholds, etc, happen to be (not even Mark).
>
> Rich
>
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>