Subject: Q.115.1 VoIP Scenario; RE: H.248.xx Enhanced Acoustic Control Package; RE: Basic Model & Near End Definition; RE: [Megaco] Question on echo control direction

From: [email-masked]
Date: Tue, 30 Mar 2004 14:49:14 +0200

I've included the Q10/11 experts because

Q.115.1 ANNEX A.2.4.3 illustrates the H.248 VoIP scenario.

Figure A.3/Q.115.1 VoIP scenario

               (Embedded image moved to file: pic15270.pcx)

A.2.4.3.1 indicates whether the half-echo control device represents an IECD
or OECD; the logical type depends on the call establishment direction. But
the echo cancellation device/function symbol in the H.248 MG keeps in both
cases the same: "reversed associated" according A.1.1 Note 1 definition.

This seems to be inline with my view stated in my first email.

Albrecht

PS
ITU-T G.108.2 Transmission planning aspects of echo cancellers
is still using near-end/far-end terminology.

                      Albrecht                                                                                                                      
                      SCHWARZ/DE/ALCAT         To:      [email-masked]                                                                         
                      EL@ALCATEL               cc:      "'Soncodi, Adrian'" <[email-masked]>, [email-masked], [email-masked]          
                      Sent by:                 Subject: RE: H.248.xx Enhanced Acoustic Control Package; RE: Basic Model & Near End Definition; RE:  
                      owner-tsg15q7@it         [Megaco] Question on echo control direction                                                          
                      u.int                                                                                                                         

                      30.03.2004 14:03                                                                                                              
                      Please respond                                                                                                                
                      to Albrecht                                                                                                                   
                      SCHWARZ                                                                                                                       

< Attachment H.248.xx Enhanced Acoustic Control Package.doc removed >

Attached Adrian's doc. Hopefully it goes through the IETF and ITU mailers.
Albrecht

(See attached file: H.248.xx Enhanced Acoustic Control Package.doc)

                      Robert Born
                      <Robert.Born@mci         To:      Albrecht
SCHWARZ/DE/ALCATEL@ALCATEL, "'Soncodi, Adrian'"
<[email-masked]>
                      .com>                    cc:      [email-masked],
[email-masked]
                                               Subject: RE: H.248.xx
Enhanced Acoustic Control Package; RE: Basic Model & Near End Definition;
RE:
                      30.03.2004 13:50         [Megaco] Question on echo
control direction
                      Please respond
                      to Robert.Born

Can anyone point the Q7/15 experts to the specific document and section
that
you want us to check regarding the HECD block?  I did not see any
attachment, nor did I see any reference to a specific document location.

Regards.

Robert Born
Editor G.799.1 draft Recommendation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, March 30, 2004 4:58 AM
To: Soncodi, Adrian
Cc: [email-masked]; [email-masked]
Subject: H.248.xx Enhanced Acoustic Control Package; RE: Basic Model & Near
End Definition; RE: [Megaco] Question on echo control direction

Adrian,

when reading the Half Echo-Control Device (HECD) section, I was reminded to
Q.115.1 and G.799.1:

ITU-T Recommendation Q.115.1
Logic for the control of echo control devices and functions

ITU-T Recommendation G.799.1

Functionality and Interface Specifications for GSTN Transport Network
Equipment for Interconnecting GSTN and IP Networks

For instance, Q.115.1 is, inter alia, providing definitions for incoming
echo control device (IECD) and outgoing echo control device (OECD), G.799.1
is extensively dealing with EC in TDM-to-Packet media gateways.

Did you already consider these ITU-T recs. in your package proposal? I
guess
that we need alignment.

May anyone of the Q7/15 experts comment on the HECD block in the proposed
H.248 package.

Regards,

Albrecht

                      "Soncodi, Adrian"

                      <Adrian.Soncodi@t         To:      Albrecht
SCHWARZ/DE/ALCATEL@ALCATEL

                      ekelec.com>               cc:      <[email-masked]>

                                                Subject: H.248.xx Enhanced
Acoustic Control Package; RE: Basic Model & Near End Definition; RE:
                      29.03.2004 21:17          [Megaco] Question on echo
control direction

Albrecht,

Still on the EC issue... I may be jumping ahead here while you are trying
to
propose a resolution, but this is what I think:

First, it doesn't look like we can "fix" the EC omission in the TDM package
without affecting either some existing MG implementations or some MGC-MG
procedures on deployed systems.

Then there are also other capabilities similar to EC, and for which there
is
currently no H.248 package. For example:
- ANR automatic noise reduction
- ALC automatic level control
- ALE adaptive listener enhancement
These are used mostly (but not only) for wireless calls.

So I was thinking we might as well define a new package, to fix the EC and
also provide the above capabilities.

Attached is an outline of what this "Enhanced Acoustic Control Package"
might contain. I did not include the "audio gain", which is defined in the
TDM package. (Maybe I should have, because this is also directional, so
apparently it has the same problem as EC.)

Please let me know what you think. If anyone is interested in pursuing this
work in the ITU-T group, please let me know.

Regards,

Adrian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 24, 2004 11:09 AM
To: Soncodi, Adrian
Cc: [email-masked]
Subject: Basic Model & Near End Definition; RE: [Megaco] Question on echo
control direction

Adrian,

you are addressing a bunch of valid questions.
Before responding on your details, I'd like to synchronize our
understanding.

Please find enclosed some powerpoint slides
(NGN_EchoCanceller_Principle_r02.PPT), these pictures reflecting my "world
view" on H.248 MG-embedded ECs:-) Do you agree with "near end", "half way"
definitions? Is my view inline with yours?

Perhaps one issue is the use of term "near end" in NGN environments,
whereas
G.168 precisely talks about "cancelled end" since the 2002 version.

Any G.168 experts view? Please correct me if I'm wrong.

Best regards,
Albrecht

(See attached file: NGN_EchoCanceller_Principle_r02.PPT)(See attached file:
NGN_EchoCanceller_Principle_r02.pdf)

                      "Soncodi, Adrian"

                      <Adrian.Soncodi@t         To:      Albrecht
SCHWARZ/DE/ALCATEL@ALCATEL

                      ekelec.com>               cc:      <[email-masked]>

                                                Subject: RE: [Megaco]
Question on echo control direction

                      19.03.2004 18:46

Albrecht,

Let's say both switches perform near-end, half way EC as you suggest. Then
the question is: what do you mean by "near-end half way EC"? Is it:
a) Cancelling echo towards the near-end user, so that he does not hear
echo?
or
b) Cancelling echo generated by the near end, so that the far end user does
not hear echo?

In other words, which one happens when the MGC instructs the MG to turn EC
on? I'm not saying it should be one or another, I'm saying that the H.248
standard should specify it, because it matters.

Kevin says it should be a). I just point out that most of the MGs today do
b). And I found one MG that does a). So if MGCs follow the ISUP procedures
to turn EC on at both ends using b), they may have the surprise that some
EC
devices are "flipped over", and thus they become ineffective as they work
over the long path. Or, instead of being complementary, both EC devices
cancel in the same direction ... you see the problem.

I don't quite understand the rest of you e-mail. What do you mean by "Any
EC
requirement in addition ... must be signalled correspondingly." Signaled
where? in H.248 you only have one ec property.

Are you suggesting that the MGC just signals "ec=on", and then the exact
behavior of the MG (i.e. the direction of the half-way EC device etc.)
depends on the local MG provisioning? This could be a solution, but even
so,
the H.248 standard should make it clear. And the MGC would still have to
know what is the case in order to properly implement two-way echo control
procedures.

To conclude, I'm still trying to find out what the MG's expected behavior
is. See my long e-mail for pros and cons of a) and b). But I believe if we
don't clarify it, there will be interop problems.

Adrian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 19, 2004 3:06 AM
To: Soncodi, Adrian
Cc: Kevin Boyle; [email-masked]; [email-masked]
Subject: RE: [Megaco] Question on echo control direction

Adrian,
I couldn't find any contradiction between Kevin's and your statements.

My understanding is that the "basic" EC settings for circuit-to-packet MGs,
where the POTS/ISDN terminal is accessed via a circuit-switched network,
are:
- near-end EC, and
- half way only ("I don't know the exact G.168 terminology").

I think that this common understanding may be derived from legacy PSTN/ISDN
networks. Any EC requirement in addition, e.g., like
- far-end EC,
- 2 near-end "H.248 TDM Terminations" (in a TDM-to-TDM call), and/or
- full way
must be signalled correspondingly.

My impression is that the "basic settings" are sufficient for almost all
cases. The additional EC capabilities are valid network scenarios (e.g.,
inter-operater interworking, replacement of an international exchange,
tandem echo cancellation, two satellite links in the TDM-to-TDM call
scenario, missing near-end EC capability in peer MG, etc), but rather
exeptional cases (like in pre-NGN TDM networks).

Regards,
Albrecht

                      "Soncodi, Adrian"

                      <Adrian.Soncodi@t         To:      "Kevin Boyle"
<[email-masked]>, <[email-masked]>

                      ekelec.com>               cc:

                      Sent by:                  Subject: RE: [Megaco]
Question on echo control direction

                      megaco-admin@ietf

                      .org

                      18.03.2004 18:13

Kevin,

In your message you say:

 "I cannot find anything that specifies this, but I don't know why someone
would use an echo canceller to cancel echo inside the context... Why not
just fix the DSP to not introduce the echo in the first place?  You don't
generally find echo on the transition from TDM<->packet."

Actually, it's not the DSP that introduces echo. It's the 4-wire to 2-wire
conversion beyond the TDM termination. So for a TDM-packet-TDM call, we
have
the following:

- Typically, echo is cancelled at both ends of the call. Originating and
terminating switch each cancel in different directions.

- For an echo device to cancel in one direction, it has to take the other
path as reference, wait for the signal to turn around from the user, and
then compare the two and clean the echo. This involves a delay buffer (echo
tail), typically up to 64 ms, sometimes up to 128 ms (I don't know of MGs
that can do more).

- As a consequence, each switch typically cancels echo over the short path.
For a TDM-packet-TDM call, the short path is usually the TDM, while the
long
path is the packet network plus the other TDM. If you wait for the signal
to
turn around on the packet side, many times the delay is bigger than the
buffer size and the EC device becomes ineffective.

- Consider two MG-s interconnected by a packet network. If these were
traditional TDM switches, each one would clean the stream going towards the
other (for example, the echo indications in ISUP IAM/ACM are designed to
achieve this result). This corresponds to the direction into the packet
network.

- Another reason to clean the stream into the packet network is that if the
stream has echo, then the encoding/decoding performed by some compression
algorithms results in lower quality voice (i.e. some algorithms are
optimized for "clean" voice).

- A solution for this would be to turn echo control on the packet-side
terminations. Then if these terminations work like you say they should, the
desired result would be achieved. Unfortunately, all the MGs I know cannot
do this. They can only apply a half EC device on the TDM termination
(probably because the package name is TDM)

- Another aspect: For a conference call with N TDM terminations in a
context, in order cancel the echo generated by one TDM circuit it is
simpler
to clean its stream going into the context than the other N-1 going out of
the context.

- Until now, I thought I knew the answer to this one. Although this does
not
seem to be clearly specified either in MGCP or in MEGACO, for all the MGs
I've seen, if you turn on echo on a TDM termination they clear the stream
going into the packet network. They reference the backwards stream to TDM,
which is turned around over the short path. So it looks like most of the
existing MGs do not work like you recommended -- people, correct me if I'm
wrong here.

- However, recently I stumbled upon an MG that behaves exactly the
opposite.
So now I really have a problem, because there is no way for an MGC to know
whether the ec property results in the insertion of a full EC device or a
half device, and which direction.

- By analogy with signals (although ec is a propery not a signal), this
should work as you said, i.e. towards the outside of the context. But if
you
would like to standardize this behavior, already a lot of MGs would be
non-compliant (again, people?).

- There is also no way for an MGC to audit for this behavior. But if MGs
were allowed to behave both ways, then you could have different MGs at the
two ends and then of a TDM-packet-TDM call, and it becomes impossible to
provide two-way echo cancellation.

So how do you propose we clarify all this?

Thanks,

Adrian

      -----Original Message-----
      From: Kevin Boyle [mailto:[email-masked]]
      Sent: Wednesday, March 17, 2004 6:12 PM
      To: Soncodi, Adrian; [email-masked]
      Subject: RE: [Megaco] Question on echo control direction

      Ecan generally applies to the network transition point to avoid
      reflections off the transition.  Therefore, it would make sense that
      the echo canceller on the TDM termination would cancel echo outwards
      toward the TDM facility.

      I cannot find anything that specifies this, but I don't know why
      someone would use an echo canceller to cancel echo inside the
      context... Why not just fix the DSP to not introduce the echo in the
      first place?  You don't generally find echo on the transition from
      TDM<->packet.

      Kevin

      -----Original Message-----
      From: Soncodi, Adrian [mailto:[email-masked]]
      Sent: Wednesday, March 17, 2004 6:51 PM
      To: [email-masked]
      Subject: [Megaco] Question on echo control direction

      Hi,

      When an MCG turns on echo control for a TDM termination on the MG,
      which one of the following audio streams becomes "clean" of echo:

      a) The stream from the termination outwards to the TDM facility, or
      b) The stream from the termination inwards into the context
      (presumably going out on another facility associated with another
      termination in the context) (I am assuming that only a half-echo
      canceller is inserted, because most of the MGs can only do that. The
      other half would be on the other termination.)

      Where is this specified? the TDM package in H.248 annex E does not
      say.

      Thanks,

      Adrian

      _______________________________________________
      Megaco mailing list
      [email-masked]
      https://www1.ietf.org/mailman/listinfo/megaco