OSLEC support

[jdaustin]

There are a couple of gotchas that they don't document.
You have to copy the /usr/src/oslec/kernel/oslec.ko to /lib/modules/<kernelversion>/misc/oslec.ko
and add
/lib/modules/<kernelversion>/misc/oslec.ko
to the zaptel line in /lib/modules/<kernel version>/modules.dep

----------------------------------------
/etc/init.d/asterisk stop
/etc/init.d/zaptel stop
amportal stop
cd /usr/src
svn co http://svn.astfin.org/software/oslec/trunk/ oslec
cd oslec
make
cp kernel/oslec.ko /lib/modules/`uname -r`/misc/.
insmod kernel/oslec.ko
cd ../zaptel
cp /usr/src/oslec/kernel/Module.symvers .
./configure
patch -p1 < ../oslec/kernel/../oslec/kernel/zaptel-1.4.9.2.patch
make
make install
grep /lib/modules/`uname -r`/misc/zaptel.ko: /lib/modules/`uname -r`/modules.dep
#if oslec.ko isn't shown add it to
/lib/modules/`uname -r`/modules.dep as a dependency for zaptel.

 

[FitnessPlus]

I'm confused.

I don't see the gotcha lines in the step by step instructions. Do these need to be done before, after, or in the middle of some of these steps?

 

[Alex728]

use all the steps after the ------------------------

this is what worked for me

Also, make sure that you use the correct patch for your zaptel version..

 

[Alex728]

oops, forgot to add that there is a typo in the above

patch -p1 < ../oslec/kernel/../oslec/kernel/zaptel-1.4.9.2.patch

should be (NB also altered for latest zaptel version as of date of this post)

patch -p1 < ../oslec/kernel/zaptel-1.4.11.patch

 

[osok]

i have to agree, most echo problems are caused by faulty tuning, or crappy lines.

software is a dumb way of solving what is really a hardware problem. (impedance mismatch and reflection out of the hybrid)

 

[rushter]

Updated OSLEC instructions with Sangoma A200 cards

I had terrible echo on the lines and discussed these things with Sangoma. Originally from previous Google searches we had somewhat determined that the best echo cancellation software for the non-hardware echo cards from Sangoma would be the Octware version of echo cancellation. Alas, we were wrong. So we found out about the OSLEC drivers and found jdaustin and Alex's great instructions and tested it out. They work perfectly for us.
We had to make a few mods to his instructions because we were using the Sangoma card and wanted to update everyone here on the updated instructions as they applied to us.

amportal kill
wanrouter stop (for Sangoma cards only)
service zaptel stop
cd /usr/src
svn co http://svn.astfin.org/software/oslec/trunk/ oslec
cd oslec
make
cp kernel/oslec.ko /lib/modules/`uname -r`/misc/.
insmod kernel/oslec.ko
cd ../zaptel
cp /usr/src/oslec/kernel/Module.symvers .
./configure
patch -p1 < ../oslec/kernel/zaptel-1.4.11.patch 
make
make install
grep /lib/modules/`uname -r`/misc/zaptel.ko: /lib/modules/`uname -r`/modules.dep
reboot

(Please note that we are using the 1.4.12 drivers and that this is the latest patch available at the time we installed it - without doing this patch these instructions did not work - so the patch is needed.)
(If all went well you should be able to reboot into your brand new 'echo-free' enviroment)

#if oslec.ko isn't shown add it to
/lib/modules/`uname -r`/modules.dep as a dependency for zaptel.

 

[WaywardGeek]

I'll make it four requests.

I hated Trixbox because of echo until they added oslec. My boss was going to throw away the system I'd configured, but then I added oslec with the new Trixbox update, and the echo is gone! I also hate AstriskNow, for more reasons than just echo, but echo is near the top of the list. Digium refuses to add any GPL'd software they don't own to their distro. I see that elastix also comes with oslec by default.

I'm currently happily using Trixbox at three locations, but since they seem to have gone over to the dark side, my next installation will most likely be pbxiaf or elastix. I'm a lazy user. I don't want to compile oslec into the kernel. I just want it to be there. Unless a strong competitor comes along, I'm going to stick with oslec-enabled asterisk distros. I see the point of keeping pbxiaf bloat-free, but skimping on voice quality is a mistake, IMO.

 

[jroper]

Echo is not always a problem, echo cancel when used on lines that do not need it can have a detrimental effect on quality as well.

Additionally, echo cancel is better done by the hardware on the card, not in software.

So if you are going to use any asterisk based system with POTs lines, you would be advised to spend the extra money on an echo cancel module to go on the line card from whatever manufacturer you purchase your card from, and ignore the software echo cancel.

Joe

 

[dghundt]

Rhino fxo cards are not too expensive. Free and high quality support are excellent. The only thing missing is echo.

 

[totalimpact]

where is 1.4.12 patch?

... (Please note that we are using the 1.4.12 drivers and that this is the latest patch available at the time we installed it ...

Where can I get this 1.4.12 patch as the latest in their svn seems to be 1.4.11????

 

[alauppe]

I'm going to dive in here. As for Joe's comment about EC reducing call quality, I'd like to describe my experience with oslec.

We have oslec running on about 25 PBX's with different varieties of T1's (PRI, CAS T1s, T1's to channel banks etc), POTS lines, Loop-start DID trunks, with Digium, Xorcom, and Rhino equipment - all across the state of PA. We deploy an identical image to all the sites for simplicity, and they all have oslec. Never once has oslec made the calls less clear. At the sites without echo, they quality of the calls remained perfect. At the sites with echo so bad mg2 didn't make a noticeable difference, oslec made the echo go away completely, and the quality at those sites is now as good as the perfect-pre-oslec sites.

In our experience, we have not found a single instance where oslec didn't perform better than mg2 - better even than the $1000 onboard ec cards from Digium! Never once have we considered disabling it, and never will we install another pbx without it. The reason trixbox and elastix include it by default is that it is that good.

One example, that you could probably guess. We had a site with 4 pots lines on an 8-port digium card. It had HWEC. The echo was so bad the HWEC card didn't help. Digium had us disable the HWEC and use HPEC, which they provided for free. It didn't help at all. We built and implemented oslec and the call quality instantly and irrevocably became perfect. Not just better - perfect.

I would HIGHLY recommend reconsidering leaving oslec out of the distribution. mg2 is the default from digium, it is installed and enabled by default by dahdi_genconf so it isn't like the status-quo leaves users with EC disabled by default. I would be more than willing to assist scripting the installation into the build scripts if lack of experience happened to be the reasons it is left out.

Oh - we don't even turn it off for our fax lines. Do that with MG2.

If you have echo, and you haven't tried oslec, you haven't tried the solution yet.

 

[alauppe]

One other thought. Digium includes a whole slew of EC algorithms in dahdi. If piaf adds one more, all it does is give the users more options (they get enabled or disabled in /etc/dahdi/system.conf PER CHANNEL.)

I understand if we don't want to patch dahdi_genconf to use oslec by default, we could at least include it in the source that gets built.

My $0.02. Thanks all!

 

[luckman212]

Are there any updated guides other than
http://blog.dmcip.com/2010/10/howto-compile-and-install-dahdi-2-3-with-oslec-enabled/

on getting dahdi built with OSLEC?
something a little more up-to-date with current 2.5/2.6 DAHDI releases (is that still possible?). alauppe any tips for installation?

 

[luckman212]

lgaetz: thanks for that link