Subject: Re: Echo Cancellation

From: "Sean Leahy" <[email-masked]>
Date: Fri, 29 Jun 2001 12:13:56 +0100

Brian,
     After further consideration, I am now clear that the echo we are concerned
with is as follows (contrary to last memo'):

     Given a configuration such as MG A (TDM A <-> ATM) <-> MG B (ATM< -> TDM
B):

     The Echo Cancellation property of the TDMC package at MG A against TDM
Termination A should prevent echo of speech from B being sent from TDM A    back
towards TDM B via the ATM Network.

     Thus in the context of the TDM-ATM MG, it is echo heading towards the ATM
rather than echo heading towards the TDM (although in the context of the
complete networked configuration it is heading away from TDM A towards TDM B).

     This is likely to be a general requirement for the TDMC package at a TDM -
ATM Gateway since the source of the echo is within the TDM Domain and the source
of the delay (that makes the echo significant) is in the ATM Domain.

     Echo Cancellation should be performed as close as possible to the source of
echo and in between the source of echo and source of delay (i. because the echo
cancellation functionality has to store a speech sample for the length of time
between receiving the incoming speech and comparing it with the outgoing speech
with the added echo and ii. because the echo is significant where delay will
follow).

     Can you accept this requirement reverses our originally agreed position
that the Echo Cancellation Property being set in the TDMC package means the MG
cancels Echo heading towards the TDM i.e. it should cancel Echo arising from the
TDM heading towards the ATM ?

     Regards,
     Sean

---

From: [email-masked]
Date: Fri, 29 Jun 2001 09:31:39 -0400

I always get confused by this stuff, so it's always nice to see others
having the same
confusion.

Let's see how much of this I get straight.

Echo occurs only when speech sent out is returned delayed.  This arises in
a couple of
ways.  The easiest to understand is acoustic echo, as in a speakerphone,
where
speech coming out the speaker is picked up by the microphone and returned.
The speaker is on the other side of the network, and he hears his own
speech
delayed by the network.  To fix this, the speakerphone side compares the
sound
coming off the microphone from sound sent to the speaker and cancels the
speaker source from the microphone feed so that what was sent to the
speaker
does not appear in the microphone stream returned to the far end.  Right?

A similar problem occurs with POTS because of the hybrid - a portion of the
incoming
speech is reflected back to the speaker by the hybrid.  If there is very
low delay in
the network, this is not a problem - you hear yourself talking in the
earpiece.
However, if the network has substantial delay, then it is objectionable.
The way we deal with this problem is echo cancel.  In North America, this
is uniformly
done at the interface between the Class 5 (local) exchange and the Class 4
(trunk)
exchange.  Let's see, the far end (B) echo cancel compares the (delayed)
speech
from A to the speech from B, and removes A so that all A hears is B, right?

Now most ATM based "local" exchanges can be designed so that they have less
than
30 ms end to end delay.  You shouldn't need EC in a "local" VoATM system if
you
control packetization delay.  The network itself has hundreds of
microseconds of delay,
plus speed of light.  However, a large network will indeed have speed of
light problems,
and thus you will need echo cancel.  I will note that you ONLY need echo
cancel if
you have a hybrid -- when you know that it's digital all the way (a
sipphone for
example), you wouldn't need echo cancel.  For now, we will probably always
assume
EC.

Okay, now we have exactly the same situation.  B cancels A's speech from
getting
sent back to A, and A cancels B's speech from getting back to B.
Now, when we say "Echo Cancellation Property being set in the TDMC package
means the MG cancels Echo heading towards the TDM".
You get to interpret this a couple different ways.  I looked at it as the
echo arises in the
TDM network, and is objectionable in the TDM network, so the statement is
correct.
Someone apparently wants to note that the way it works is to change the
stream of
bits heading into the ATM Network, and thus is not correct.  Okay.  It's
still in the TDM.
The ATM network doesn't cause echo, and has no need of canceling it.

Brian

    -----Original Message-----
   From:   Leahy, Sean
   Sent:   Friday, June 29, 2001 7:14 AM
   To:     Rosen, Brian
   Cc:     [email-masked]
   Subject:  Re: Echo Cancellation

   Brian,
      After further consideration, I am now clear that the echo we are
   concerned with is as follows (contrary to last memo'):

      Given a configuration such as MG A (TDM A <-> ATM) <-> MG B (ATM< ->
   TDM B):

      The Echo Cancellation property of the TDMC package at MG A against
   TDM Termination A should prevent echo of speech from B being sent from
   TDM A   back towards TDM B via the ATM Network.

      Thus in the context of the TDM-ATM MG, it is echo heading towards the
   ATM rather than echo heading towards the TDM (although in the context of
   the complete networked configuration it is heading away from TDM A
   towards TDM B).

      This is likely to be a general requirement for the TDMC package at a
   TDM - ATM Gateway since the source of the echo is within the TDM Domain
   and the source of the delay (that makes the echo significant) is in the
   ATM Domain.

      Echo Cancellation should be performed as close as possible to the
   source of echo and in between the source of echo and source of delay (i.
   because the echo cancellation functionality has to store a speech sample
   for the length of time between receiving the incoming speech and
   comparing it with the outgoing speech with the added echo and ii.
   because the echo is significant where delay will follow).

      Can you accept this requirement reverses our originally agreed
   position that the Echo Cancellation Property being set in the TDMC
   package means the MG cancels Echo heading towards the TDM i.e. it should
   cancel Echo arising from the TDM heading towards the ATM ?

      Regards,
      Sean

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 29 Jun 2001 15:58:23 +0100

Brian,
      I think we are basically in agreement now.

     You wrote : "B cancels A's speech from getting sent back to A, and A
cancels B's speech from getting back to B."

     Yes, agreed.

     You wrote: "Echo Cancellation Property being set in the TDMC package
means the MG cancels Echo heading towards the TDM. You get to interpret
this a couple different ways.  I looked at it as the echo arises in the
TDM network, and is objectionable in the TDM network, so the statement is
correct."

     O.K. but we were looking at a TDM <-> ATM Media Gateway and thinking
in that context we want to clarify that the echo being cancelled is going in the
direction
towards the ATM (albeit it would later emerge back in the TDM somewhere where it
would be objectionable).

     You wrote: The ATM network doesn't cause echo, and has no need of canceling
it.

     O.K. but the packetisation before getting into the ATM causes delay which
is
significant in making the echo noticeable later on especially if there may be
multiple
TDM -ATM-TDM packetisation/de-packetisation on the way to the destination.

     Thanks,
     Sean

CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 29/06/2001 14:31:39

                                                              

 To:       Sean Leahy/MAIN/MC1@MCMAIN                         
                                                              
 cc:       [email-masked]                                    

 Subject:  RE: Echo Cancellation                              

Brian

    -----Original Message-----
   From:   Leahy, Sean
   Sent:   Friday, June 29, 2001 7:14 AM
   To:     Rosen, Brian
   Cc:     [email-masked]
   Subject:  Re: Echo Cancellation

   Brian,

      Regards,
      Sean