Re: AW: AW: AW: asterisk 1.11 and chan_misdn

On Wed, 05 Jun 2013 07:30:55 +0200, Hirschmüller,_Sven  
<Sven.Hirschmueller-Xt/TTPqwsUlWk0Htik3J/[email protected]> wrote:

I guess many of those finings have been ralated to the old mISDN.
BTW: You are aware that the two mISDN versions are very different?

> 1) Lcr had high latency in audio transmission that made the use of FAX  
> machines difficult.

I never tried fax, but, yes there have been some minor issues until  
recently that can be bad for fax.

> 2) Attempts to establish a ISDN-PPP dial in connections via "app_pipe"  
> didn't succeed. (Guess No. 1 was the problem as we got trillions of  
> corrupted packages.)

The last time I tried PPP was with I4L. :-)

> 3) Hold/Retrieve didn't worked reliable not to say crashed reliable .)

Definitely an mISDN1 issue, which even may still exist. I got it while  
comparing features not too long ago.

> 4) Bearer-Capabilities couldn't be set.

Does work

> 5) Key-Pad/DTMF hick-ups.

Works very well in both directions and is one of the parts where dahdi has  
issues.

> 6) Stability issues (most likely gone.)

yes

> 7) Caller-ID, Called-Party-No got mixed up.

I'm not aware of anything like that, no matter what version.



>> True stories, but you can reduce the number of IRQs for at least some  
>> hardware drivers by the use of a module >parameter.
>> But the number of IRQs is not really the issue. The amount of CPU time  
>> spent in the interrupt handler is.
>> As every programmer should know it is essential to keep the time spent  
>> in an interrupt handler as low as any >possible and to use other  
>> techniques like re-scheduling or callbacks if you need more time.
>> Unfortunately DAHDI has all audio processing DSP routines (echo  
>> cancelling and conference mixing) done in the >interrupt handler. That  
>> should be a definite no-go IMHO and can indeed cause a lot of trouble.
>
> Yes i can support that statement. Our system load with Digium hardware  
> is 2..0 even though the CPU, IO, Sys and Mem (iowait is 0.0) allocation  
> is 0.01%...with about 5k IRQs. the joke is that the same setup with  
> openvox cards runs with 0.01% load. Who understands linux load  
> indication :) The only idea i had is that tons of crunching power is  
> used in the IRQ handlers.

You need to have 'Fine granularity task level IRQ time accounting' enabled  
to be able to see what's going on.

> The openvox version of the driver quite regularly misses to initialise  
> one of the cards (guess thats a udev issue) and crashes always if you

mISDN even supports hotplugging :-)

> try to unload it. I come to live with that as the mISDN stuff did that  
> also.

As said at the beginning, making assumptions for mISDN2 based on mISDN1  
doesn't make sense.
And surely DAHDI has become a lot better. But neither solution is anywhere  
near perfect and which one is better depends on which features you need  
and which ones you can live without.
(and hope you don't need them both)

If you like playing around with Asterisk like I do, the fact that LCR will  
continue to work without Asterisk is a nice bonus.

   Greetings,
     WIMPy