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

Yes i'am aware the mISDN v1 and v2 can't be compared.

As told my experience is aged and as you guys proved most of the problems seem to be gone. 

If i had some more "play" time i would like to check the capabilities of LCR again but for the time being we will stay with dahdi even though i want to visit Digium or OpenVox and argue with a baseball bat with them, sometimes :) 

It's more or less a choice witch devil you want to summon.

Thx for all the replies and for the hints btw.

g.
Sven




-----Ursprüngliche Nachricht-----
Von: isdn4linux [mailto:isdn4linux-bounces-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp@public.gmane.org] Im Auftrag von Birger Harzenetter
Gesendet: Samstag, 8. Juni 2013 00:03
An: [email protected]
Betreff: Re: AW: AW: AW: asterisk 1.11 and chan_misdn

On Wed, 05 Jun 2013 07:30:55 +0200, Hirschmüller,_Sven <[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
_______________________________________________
isdn4linux mailing list
[email protected]
https://www.isdn4linux.de/mailman/listinfo/isdn4linux