VoIP Mailing List Archives

[oseslija at gmail.com]

To share my experience: I had issues with echo with many E1 trunks in Serbia, especially when voice in between telco's network went to well known bad analog lines. I used OSLEC and I was fortunate to have Steve to complain to, he helped patching it further after my beta testing. Not many people would do that imho.
 
I now switched to Sangoma cards with Octasic chips and occasionally would still hear certain echo. 
My view is that here some echo cancelling solution is very necessary, otherwise whole VoIP business comes up to bad reputation People would just not listen to themselves speaking, even using $400 phone. 

Regards,
Ognjen

2009/3/18 David Knell <dave@3c.co.uk (dave@3c.co.uk)>

[dave at 3c.co.uk]

Hi Arnaldo,

That's interesting - Brasil was my first proper IVR installation: one
with Embratel in Sao Paulo, and then a couple with TeleRJ. I remember
landing at Sao Paulo airport for the first time at 7 a.m. with
instructions to "meet a fat man called Ferrari" unsure as to whether I
was in some sort of elaborate hoax (I wasn't, and he was), and learning
my first three words of Portuguese as we left the car park: filho da
puta, of course.

Those had no EC. DTMF detection worked fine, and the audio quality of
the IVR recordings was perfect, which is what you'd expect: EC doesn't
alter the IVR->caller audio at all. A TDM->SIP->TDM type application is
a different animal: you've got the added latency of packetisation/jitter
buffering/etc. which pretty much makes echo cancellation a must.

--Dave

[steveu at coppice.org]

OK, one last go and I give up.

Lets look at the documentation for Dialogic springware. This is the DSP
package that loads in their cards or runs on the host in HMP
applications. It does things like DTMF generation and detection for all
Dialogic cards except the DM3 series. The documentation says:

*PerfectDigit DTMF Signaling*

• DSP-based DTMF (touchtone) detection algorithm optimized for lowest
talk-off and play-off susceptibility in the industry. The system will
not easily be fooled by mistaking human speech for DTMF tones.

• Minimum tone duration and interdigit delay times accurately handle
speed dialing typical of "power users"

• Utilizes echo cancellation which results in superior cut through for
accurate DTMF tone interpretation during voice file playback within a
broad range of network/switch environments

• DTMF outbound dialing generated by DSP for accuracy and flexibility
(dialing levels are adjustable to meet a variety of global PTT requirements)


Detecting supervisory tones on phone lines is trivial. Not falsely
detecting them is where things get interesting. The standard test for
DTMF receivers is a set of cassette tapes from Bellcore containing about
3 hours of snippets from real telephone calls in North America. Most
DTMF receiver chips get a few hundred false DTMF hits in those 3 hours.
Dialogic get 20 something. My DTMF receiver gets 19. The reason its hard
to detect these things reliably is voice doesn't sit there nicely at one
level. Its level and its spectrum bounce all over the place, and a real
DTMF digit is only there for 40ms or so. I defy anyone to visually
identify a 40ms DTMF digit amongst real dynamic speech if it isn't *way*
above the voice in amplitude. This is why your phone has to mute your
voice when you press a digit. The DTMF receiver has no chance of
reliable detection with speech and digits mixed. In the few special
cases where concurrent speech and signaling tone are present on the PSTN
(e.g. 2280Hz signaling in .eu and 2600Hz in .us) the signaling sequence
is very carefully constructed to avoid confusing the system. DTMF is
never used in that way.

There is one obvious special case where all DTMF receivers need to
tolerate spillback. They need to differentiate between dialing tone and
DTMF on the first digit you dial. They do this very simply. Dialing tone
was chosen to be pretty low frequencies - 350Hz + 440Hz, 425Hz + 475Hz
and similar pairings. The lowest DTMF tone is well above this. An
aggressive low pass filter in the DTMF receiver removes the dial tone
spillback, while barely affecting the lowest DTMF tone. This was the
original design of DTMF, but......

IVRs changed all that. Their DTMF receivers are expected to work amidst
outgoing prompts, which may be going to phones with an awful match to
the line. The spillback can be huge. The good IVR hardware suppliers,
like Dialogic, very quickly added echo cancellation to their cards. I
can say a lot of negative things about Dialogic, but one thing they did
really well was their DTMF cut-through. When people get used to an IVR
they expect to hammer in digit sequences as fast as they can, in the
face of a machine desperately trying to play voice prompts to them.
Dialogic cards do this really well, on lines of all types, and on
networks of varying quality. This would be impossible without echo
cancellation.

David Knell wrote:

[intralanman at freeswi...]

David Knell wrote:

[dave at 3c.co.uk]

Raymond Chandler wrote:

[anthony.minessale at g...]

Well,

From my experience, an AS5300 thinks nearly *anthing* is dtmf.
The one I have as a PSTN onramp to our conference bridge drives me bonkers with false positives
since every key on the pad means something in our default conference.

Jim Dixon designed the el-cheapo (tormenta 2) to put as many resources on the host as possible, that was the goal behind the initiative.
The driver for this card was the template on which the entire Zaptel (now Dahdi) was based.

What's interesting is that early zapata library (a user space abstraction lib) was completely consumed by chan_zap and from there
may of the featues were gravitated towards the linux kernel then eventually into the hardware as new cards were developed.

The typical reason for this kind of evolution is customers.  When there was no TDM to be had at all, el-cheapo and software was the bees knees.
As they started getting more greedy and anxious for higher quality, they started asking for improvements that lead to more stuff onboard in the new cards.
I am guessing this will continue until the cards are too expensive and we will go full circle back to all-on-host just in time for the 16 core CPU box being standard issue.

It all depends on the strategy employed, if you want to use a tor2 and oslec, (a software echo canceller that, in fact has none other than Steve Underwood from this thread as a collaberator) then do it.  If it ain't broke, don't fix it.....If you prefer to have hardware EC, then buy a card that supports it.

------
see http://www.rowetel.com/ucasterisk/oslec.html
Background and Credits
Oslec started life as a prototype echo canceller and G168 test framework from Steve Underwood's Spandsp library. Steve wrote much of the DSP code used in Asterisk, and the Zaptel echo cancellation code is heavily based on his work.
------

Bottom line: There is no real correct answer because it depends on what your goals are and what you personally prefer.

I personally have used both, I am annoyed with hardware EC because it breaks software dtmf but now the sangoma drivers have hardware dtmf to use together with hardware EC so that solves the problem.  

I would prefer not to take any sides in this debate since everyone on this thread has contributed greatly to our project and I respect them all.
I would, however, like to ask that maybe we can channel all of this intelligence into some common goal and do somethng great rather than
spend our energy doing the techno-geek version of m&m freestyle rapping.



On Sat, Mar 28, 2009 at 8:44 AM, David Knell <dave@3c.co.uk (dave@3c.co.uk)> wrote:

[f.koliqi at gmail.com]

[steveu at coppice.org]

Fadil Berisha wrote:

[f.koliqi at gmail.com]

[steveu at coppice.org]

Fadil Berisha wrote: