mISDN patches


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:


Today our new SNOM M3 with four handsets arrived, and frustration started again :) Somehow, music on hold isn't stopped on SIP transfer.

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!)


If you have trouble compiling LCR in latest versions and / or problems receiving faxes using RxFax / spandsp, this patch might be for you.

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!)


Again: nothing new on OSLEC, but there will be some news soon, since Andreas Eversberg made RESTART-handling finally work correctly in mISDN-socket branch. (Many thanks to him for his great support and patience in fixing this issue!)

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.


Nothing new on OSLEC, had to beat mISDN-GIT into a stable state with our brand new BN2E1 running before our Alcatel OmniPCX. Usefull patches so far:


Wrote an untested patch against mISDN-GIT, that adds a configurable extra-delay to the TX-buffer seen by the echo-cancellor to compensate for the pure delay that mISDN generates. (See my previous notes about delays to understand the problem...)



Fixed the 7-bit encoding according to Andreas patch. You can find the updated version here:



Fixed the 7-bit encoding (for crypto channels) within the ALAW-patch. You can get the updated version at the original place here:


(I changed Rowe's patch below also...)


My ALAW patch fixed the noise problem, but we have still a _big_ delay problem left.

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...):

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:


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."


David Rowe noticed, that converting from alaw -> linear -> alaw obviously doesn't really work within mISDN. After a little bit of twiddling, I noticed, that ALAW-conversion seems to be totally broken. (I compared the ALAW and ULAW tables to the output of sox and the output of the functions included within Asterisk core.

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 :-)


Nenad Radosavljevic added MMX-support to the v1.1.5 of the patch. You can find the result here:


Thanks Nenad!


No update on mISDN yet, but I found it worth to mention, that the latest release of sjphone (also the free version) has integrated support for acoustic echo cancellation, which works pretty well.

You can even put the headset on the desk and the other party can shout into the phone _without_ any noticable echo :-)


Noticed, that still some tx_gain manipulation is necessary, but the defaults aren't very nice. (Range -8 up to 8 scales the signal by power(2,value) which isn't very finegrained).

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: this patch adds OSLEC support to current GIT of mISDN as a seperate echo cancellation driver. It was directly ported from the zaptel-version.

mISDN_oslec_patch v1.1.5: Same for version v1.1.5 which is used in production here on two servers.