Here you'll find patches for mISDN that I produced on my way to a working (read: echo free) solution for our telephony system.
If you want to accelerate my development efforts, feel free, to use my paypal-donation link:
I'm not totally sure, if this is LCR's fault, I have the impression, that the problem lies more within SNOM firmware or Asterisk.
Anyways: I currently can't see a reason, why MOH should still be active, if lcr_bridge succeeds.
this patch stops MOH on bridging unconditionally, by sending down a RETRIEVAL message on the first channel!
Works for me now, might help you, probably is nearly the right solution, we'll see...
(this patch sanitized is now in GIT, no need to patch LCR anymore!)
You have to add lcr_config(r) to the dialplan, otherwise packets don't have the right size(160 bytes) to be processes correctly by RxFax.
Anyways: enjoy!
(this patch is now in GIT, no need to patch LCR anymore!)
That means: current socket branch just works great (tm) in our configuration. No crazy module loading / unloading, hopefully no long time crashes caused by silly locking issues within the channel driver (lcr / chan_lcr / misdn-socket has a much better design than the older mISDN version, especially the chan_misdn driver has a lot of race conditions, where several threads can manipulate the same global structure at the same time, thereby causing crashes once every two days in our configuration.).
So my advice: go, get the socket branch, test it thoroughly, Andreas and I will happily fix any missing issues.
Especially if you are annoyed by facts like:
Sidenote: Did I already mention, that, like in older versions of mISDN, it is very much recommended to use a 1000 Hz kernel? There are some buffer-overflow issues, that can happen in rare cases when using 300 Hz e.g. . Andreas is currently working on this issue, but in the meantime: use 1000 Hz.
Get a working asterisk-1.4-bristuffed, use the beronet cwain patch, then apply my watchdog patch.
You only need to install zaptel, but don't need to use it!
Now: unload your misdn drivers, do a modprobe cwain, wait 2 seconds, unload it, wait 2 seconds, load your misdn drivers again, wait again to let them settle down, start your asterisk, wait.
Doesn't work every time, but most of the time, it does. Don't know if I have to hate mISDN or Alcatel, but it caused some headaches... For a detailed discussion, you can take a look at this thread (german only). Something is wrong within the hfc_multi.c initialisation code and someday I will find out. But for now, we have at least a working hack.
(I changed Rowe's patch below also...)
For better debugging, David Rowe added some more debugging functions (sampling before / after-support, /proc/oslec-debugging, etc.)
You can find his patch against mISDN v1.1.5 here (includes all my other
patches OSLEC / volume / ALAW also...):
mISDN_oslec_patch_v1.1.5_rowe
Anyone familiar enough with mISDN core should take a look at it, so that we can find out, where this delay is generated.
(Some example echo captured with this patch:
Quoting David:
"I have added my sampling code to mISDN and captured a few samples. In the attached plots I have replaced the "tx" speech with a series of impulses - these are useful in characterising the impulse. A bit like "ping" in networks. BTW the blue (ec) and green (rx) are superimposed on each other as the ec signal is identical (ie no echo cancelled). If Oslec was working ec would be a flat line, all the rx echo would be eliminated.
BTW for definitions of the various terms (tx, rx, ec) I use pls see this post:
http://www.rowetel.com/blog/?p=18
So I think the problem is the large "pure delay" component of the echo - after each impulse you can see it takes about 350 samples before the echo comes back. Normally for FXS ports this pure delay is just a few samples, you see the echo straight after the impulse, for example here is the rx (echo) signal from an impulse at times 0 (impulse not illustrated):
Oslec can't cope with the big delay - it can only correct echo in the first 128 samples (or 256 samples in 256 tap mode). 350 samples of pure delay is 350/8000 = 43.75ms.
So the question is "where is this big delay coming from"? It could be in the buffering logic of mISDN (e.g. dsp_cancel_tx), or it could be in the TA 33 ISDN-FXS converter I am using. Or perhaps in a deeper layer of mISDN, or even the hardware.
I don't think the delay is in the TA33 or ISDN hardware, as I think that this sort of delay would cause echo even without Asterisk, i.e. in a normal ISDN phone call:
A - ISDN phone - ISDN network - TA 33 - Analog phone - B
Also I imagine ISDN phone components are designed to have minimal delay so that normal (non VOIP) calls don't need echo cancellers. So my guess is this delay is being introduced by mISDN somewhere. In addition we know bristuff/zaptel works OK (with similar hardware).
When we call the echo_can_update() function we present it with the rx and tx signals. The idea is we need to get tx and rx "closer" together, i.e. more time aligned."
ULAW is very similar, ALAW is, well something totally different, but it is _not_ ALAW... and both Asterisk and SOX are consistent with each other.)
I wrote a patch, that adds the ALAW and ULAW code of Asterisk to mISDN. (If now something goes wrong again, one can at least take a look _how_ these tables were generated...)
You can find the patch against mISDN 1.1.5 here:
In case you downloaded already the untested version: I forgot the bit_reverse operation, that is also necessary. Hopefully, I haven't destroyed anyones ears. Works great for me, hopefully others are happy, too :-)
Thanks Nenad!
You can even put the headset on the desk and the other party can shout into the phone _without_ any noticable echo :-)
mISDN_volume_patch: this patch adds
more finegrained volume levels. (Creating the following range:
1=1.10, 2=1.25, 3=1.50, 4=1.75, 5=2.0, 6=3.0, 7=4.0, 8=5.0
(and the inverse in the opposite direction.)
Noone sensible will use a amplification factor above 5.0 IMHO, but
proof me wrong :-)
We'll see tomorrow, if our customers like the setting of -1 that I chose...
mISDN_oslec_patch v1.1.5: Same for version v1.1.5 which is used in production here on two servers.