Subject: Re: Echo Cancellers

From: "Hari Krishna Vuppaladhadiam" <[email-masked]>
Date: Wed, 26 Apr 2000 15:12:19 -0700

Hi,
  I see in many of the company websites of VoIP specifying Echo cancellers
(ITU-G.165/G.168) standards. When it comes to delay it goes upto 128 msecs.
Now I understand a case where Mobile networks is involved, one can find
larger delays.
It takes lot of MIPS to run Echo cancellers for larger delays. Where do I
get information regarding the DELAY?
And also the necessity of an Echo canceller for say a residential gateway or
an enterprise gateway?

Hari

-----Original Message-----
From: Scott Keagy <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Hari Krishna Vuppaladhadiam <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, April 26, 2000 2:58 PM
Subject: Re: Echo Cancellers

>Kevin et al,
>
>feel free to correct me if I'm wrong in the details below....
>
>I added more details to the diagrams to clarify what we're talking
>about.
><see diagrams at bottom>
>
>
>ITU Echo Canceller Requirements
>-------------------------------
>
>ITU-T Recommendation G.131 "Control of Talker Echo" (section 4.1) states
>the following:
>"In general, it is recommended that the active echo control devices
>shall be deployed on all connections which exceed the total one-way
>talker echo transmission path time of 25 ms."
>
>This implies that public phone networks may not provide echo
>cancellation for tail-end hop-off circuits that have up to 50 msec
>round-trip latency.
>
>
>Where echo originates
>---------------------
>Impedance mismatches at 2-wire/4-wire hybrids (transitions from 2-wire
>to 4-wire circuits) can cause signal reflections. The likely spots where
>these hybrids can cause problems for VoIP hop-off scenarios are
>illustrated below. Carrier equipment may not be optimally tuned, or
>customer equipment may not be optimally tuned. In addition to these
>spots, acoustic echoes may occur from the destination speaker/mic
>equipment (i.e. speakerphone or cheap telephone handset).
>
>I submit as proof that not all networks are ideally designed, that I
>frequently call residential locations in India from the U.S. I here my
>own echo on at least half of the conversations, which implies that some
>telco central offices in India have poor hybrid terminations.
>
>
>What a company can do about it
>-------------------------------
>Given the ITU recommendations that support a carrier's right to not
>employ echo cancellers in medium-delay networks (i.e. up to 50 msec
>round-trip), a company employing a VoIP solution has no recourse to
>block the echo other than to use echo cancellers with high delay
>coverage, as illustrated below. A given company can't fix the network
>problems for different calling destinations (i.e. adjust the impedance
>coupling at the hybrid to increase the return loss), but it can take
>personal action to defend the voice quality experienced by its
>employees.
>
>Note that this is an enterprise-centric approach to the problem. A
>carrier-centric approach might be to negotiate with the remote telco to
>fix the problem, so that the local carrier does not get stuck with the
>echo-canceller bill. So high delay echo cancellers may be useful for
>low-end and enterprise products, but not for carrier products. Also note
>that up to 64 msec is sufficient given that all networks are designed
>according to ITU spec.
>
>
>==== : 4-wire circuit
>---- : 2-wire circuit
>
>**************************************************************************
>                                                  ||=====<digital user
>C>
>                                                  ||
>                                                  ||
><user A>=====<VoIP cloud>===<long delay PSTN>====<PBX>-----<analog user
>B>
>                        ^                             ^
>                        |                             |
>                        |                             |
>                        |                 (signal from A reflected here)
>                        |
>                   (High delay echo canceller needed here)
>
>**************************************************************************
>
><user A>=====<VoIP cloud>=====<long delay PSTN>-------<user B>
>                        ^                     ^
>                        |                     |
>                        |                     |
>                        |            (signal from A reflected here)
>                        |
>                   (High delay echo canceller needed here)
>
>***************************************************************************
>
>-Scott
>
>[email-masked] wrote:
>>
>> Scott:
>>
>> Thanks for you input to the group on this subject.  There seems to be a
>> considerable amount of misunderstanding about echo control with VoIP
networks.
>> I repeat a label your networks below to make some points of discussion:
>>
>> Case 1:
>>      <user A>----<VoIP network>----<PSTN>----<mobile network>---<userB>
>>
>> Case 2:
>>
>>      <VoIP network>----<PSTN>-------<VoIP network>
>>
>> Case 3:
>>
>>      <VoIP network>----<any high delay hop-off to PSTN>
>>
>> In case 1, user A has a four-wire connection to the network and user B
also has
>> a four-wire connection to the network.  That is - unless somewhere in the
mobile
>> network or in the PSTN there is some two wire circuits.  Unless user A is
using
>> a poor quality speakerphone, there should be no need for any echo
cancellation
>> at all.
>>
>> for case 2, there should also be no need for any echo cancellers unless,
again,
>> the PSTN has been poorly engineered and has two-wire connections
somewhere.
>>
>> For case 3, it the right side of the network has a Media Gateway.  At
some point
>> to the right of that gateway there will be a two-four wire hybrid which
will be
>> the source of an echo.  The echo would be user a "talker echo".
Therefore, the
>> media gateway has ther responsibility of echo cancelling this echo.  This
is
>> typicaly short - as in certainly less than 20 msec.  It is true - that
the
>> longer the VoIP network delay, the better the echo canceller in the
network must
>> work.  This is why it is important for VoIP networks to manage their
delay
>> downwards as much as possible.  To do otherwise causes a) the media
gateway echo
>> canceller to "work harder" than it should have to and b) cause
conversational
>> double-talking that is subjectively annoying even when the echo control
is
>> perfect.
>>
>> The basic misimpression that I see all too often is that people believe
that
>> "station side" or subscriber equipment echo cancellers need to be
deployed at
>> the subscriber or user's equipment.  This is, for the most part, untrue.
If it
>> turns out to be true, someone architected their network poorly.  Echo
cancellers
>> with long tail coverage are an expensive commitment to poor network
design.
>>
>> If I recall correctly, even with normal characteristic impedances in
cable (free
>> space is faster) a tail circuit across the country will not exceed 20
msecs.
>>
>> Kevin
>>
>> Scott Keagy <[email-masked]> on 04/26/2000 03:48:08 PM
>>
>> To:   Hari Krishna Vuppaladhadiam <[email-masked]>
>> cc:   [email-masked] (bcc: Kevin Bruemmer/Natural MicroSystems/US)
>> Subject:  Re: Echo Cancellers
>>
>> I think there is a good application for high-delay echo cancellers.
>> Consider the following scenarios:
>>
>>      <user A>----<VoIP network>----<PSTN>----<mobile network>---<userB>
>> or
>>      <VoIP network>----<PSTN>-------<VoIP network>
>> or
>>      <VoIP network>----<any high delay hop-off to PSTN>
>>
>> Typical echo cancellers at the edge of the VoIP network (e.g. Cisco
>> routers) only provide 32 msec of coverage. If a hop-off tail circuit has
>> a round-trip delay that exceeds the coverage of the echo canceller (on
>> the outbound edge of the VoIP network), then the additional delay of the
>> VoIP network (100 msec or more usually) exacerbates the echo problem.
>>
>> This is an intractable problem without the use of echo cancellers that
>> have longer coverage ability.
>>
>> -Scott
>>
>> Hari Krishna Vuppaladhadiam wrote:
>> >
>> > Hi,
>> >   I am interested in knowing what kind of echo cancellers do we require
in
>> > typical VoIP applications. Is there a requirement for delays greater
than
>> > 64msecs?
>> >
>> > Regards
>> > Hari
>>
>> --
>> =======================================================
>>  Scott Keagy, CCIE #3985
>>  Senior Networking Consultant
>>  SK Networks, Inc.         mailto:[email-masked]
>> =======================================================
>
>--
>=======================================================
> Scott Keagy, CCIE #3985
> Senior Networking Consultant
> SK Networks, Inc.         mailto:[email-masked]
>=======================================================

---

From: [email-masked]
Date: Thu, 27 Apr 2000 10:27:18 -0400

Jon:

Unless I misunderstand what you are saying below, you should confuse the end-end
delay of an entire connection with what coverage the echo canceller must have.
The network echo canceller (G.165/G.168 definition) should cancel the echo as
reflected on the far end.  In other words, the echo canceller's responsibility
is to cancel the talker echo at or near the two-four wire hybrid at the
listener's end of the connection.

Kevin

Jon Crowcroft <[email-masked]> on 04/27/2000 03:20:19 AM

To:   Scott Keagy <[email-masked]>
cc:   Hari Krishna Vuppaladhadiam <[email-masked]>, [email-masked] (bcc:
      Kevin Bruemmer/Natural MicroSystems/US)
Subject:  Re: Echo Cancellers

 >>have longer coverage ability.

 Scott

well a well engineered path from London to San Francisco consistently
has a delay of around 150ms.... (see below) - i dont see why someone
cant think a bit about echo cancellors for this.....references would
be interesting on why it is "intractable" - is it only if the delay is
also highly variable (the path below has low delay variance - probably
lower than a lot of paths with lower e2e delays by about an order of
magnitude)

j.
1  cisco (128.16.6.150)  1.290 ms  0.822 ms  0.774 ms
 2  cisco-pb (128.40.14.245)  1.037 ms  1.005 ms  0.931 ms
 3  10.0.121.5 (10.0.121.5)  1.091 ms  1.116 ms  0.943 ms
 4  128.40.255.153 (128.40.255.153)  1.011 ms  0.978 ms  0.961 ms
 5  atmr-ulcc.lmn.net.uk (194.83.100.62)  2.442 ms  2.072 ms  2.861 ms
6  146.97.255.65 (146.97.255.65)  2.888 ms  3.083 ms  3.552 ms
 7  us-gw2.ja.net (128.86.1.242)  2.644 ms  4.118 ms  4.282 ms
 8  193.62.157.10 (193.62.157.10)  77.606 ms  78.305 ms  76.007 ms
 9  ny-pop.i2.ja.net (193.62.157.2)  76.505 ms  77.377 ms  77.356 ms
10  clev-nycm.abilene.ucaid.edu (198.32.8.29)  91.581 ms  91.423 ms
91.912 ms
11  ipls-clev.abilene.ucaid.edu (198.32.8.25)  97.521 ms  97.082 ms
97.209 ms
12  kscy-ipls.abilene.ucaid.edu (198.32.8.5)  106.739 ms  106.723 ms
106.687 ms
13  denv-kscy.abilene.ucaid.edu (198.32.8.13)  117.296 ms  117.093 ms
117.063 m
s
14  scrm-denv.abilene.ucaid.edu (198.32.8.1)  139.592 ms  140.627 ms
138.953 ms
15  BERK--abilene.POS.calren2.net (198.32.249.41)  142.507 ms  142.512
ms  142.5
65 ms
16  pos1-0.inr-000-eva.Berkeley.EDU (128.32.0.89)  142.498 ms  142.269
ms  142.5
63 ms
17  pos5-0-0.inr-002-eva.Berkeley.EDU (128.32.0.74)  139.891 ms
139.231 ms  139
.991 ms
18  fast9-0-0.inr-010-cory.Berkeley.EDU (128.32.0.42)  140.512 ms
141.192 ms  1
40.178 ms
19  f1-0.inr-181-soda.Berkeley.EDU (128.32.120.181)  144.808 ms
143.865 ms  144
.345 ms
20  router1.ICSI.Berkeley.EDU (192.150.186.2)  146.302 ms  145.192 ms
146.140 m
s
21  www.aciri.org (192.150.187.11)  146.306 ms  153.327 ms  146.852 ms

---

From: [email-masked]
Date: Thu, 27 Apr 2000 16:35:22 -0400

I believe that you are assuming that the company has only one gateway.
Generally, each location will have a gateway.
Do you agree?

---

From: [email-masked]
Date: Fri, 28 Apr 2000 18:54:46 -0400

Thanks for the detailed reply.  That scenario indeed looks like it calls for a
(moderately) long echo canceller.