Re: asterisk 1.11 and chan_misdn

Hirschmüller, Sven schrieb:
> Hi Guy,
>
> sorry for hijacking the thread but i guess that may be interesting for others also.
>
>>> I didn't tried to build chan_lcr and mISDNv2 as they missed some
>>> features in the past. (Don't know if that changed.)
>> Which ones?
>> (Trying to keep the comparison up to date which it may not really be ATM)
> As you saw my experiences are quite aged but in that time we had following issues.
>
> 1) Lcr had high latency in audio transmission that made the use of FAX machines difficult.
Sending or Receiving?
I use asterisk faxreceive without problems. Ok not that much just 2 
faxes a day.(The rest is received with avm fritzcard over chan_capi.
which are more than 15 faxes a day.)
Everything without problems.
I have more problems with asterisk hanging in the voice part-> 
misdn_error -12?
Means every 2 month one kill -9 of asterisk and everything works fine again.

lcr and misdn driver are stable! no problems with this. No restarts or 
unloads to do.

> 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.)
> 3) Hold/Retrieve didn't worked reliable not to say crashed reliable .)
No problems here.
> 4) Bearer-Capabilities couldn't be set.
> 5) Key-Pad/DTMF hick-ups.
Every day I enable and disable the German T-net box with keypad from 
chan_lcr.
No problems with that.

DTMF is sometimes hearable in the voice part, but only female voices 
have problems. Maybe I have to play around with some
options.
> 6) Stability issues (most likely gone.)
Yes
> 7) Caller-ID, Called-Party-No got mixed up.
Only if I put an incoming call on hold and transfer it on another phone. 
But who cares ;)

>
> I guess that were the most problematic ones and we needed to get PPP dial in connections via asterisk running. (Not needed anymore on our side.)
>
>> As said DHADI is a performance pig .. the IRQ quote is so high that
>> many mainboards have problems to handle that and you often get the
>> helpful answer from the support crew .. try another PCI slot. Running
>> multiple cards at once can be really difficult. The cards hate
>> IRQ-Share and we hunt a random crash of the system in the moment and
>> i'am afraid that is simply a bug of the cards driver if the system
>> IRQ-Load is reaching the boards capacity.
>> 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.
>
> Still i want to be fair .. the Digium stuff worked out of the box, the building of the driver is very smooth. You can see that they invested quite some time in the makefile and configure scripts and the handling of the cards is quite easy. It's really nearly plug and pray. As long as you stays with Digium hw and don't want to use multiple cards at once. 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 try to unload it. I come to live with that as the mISDN stuff did that also. I also need to hack it to set a second card installed to different nt/te settings then the first one.
>
> I would like to run a new test with mISDNv2 and lcr but i guess my colleagues and boss will shoot me if i suggest another test run with mISDN as we had so many problems to get them running in the past.
>
> G.
> Sven
Hmm, for me it sounds a little bit like changing the side but almost 
with the same weight of problems ;)
But thanks for the report. I will stick with chan_lcr. I´m trying 
asterisk 11 and the lcr,capi stuff.
Let´s see how this works.
Because of this
http://forums.asterisk.org/viewtopic.php?f=1&t=86221
and maybe that leads to misdn_error -12?
Just another try ;)


-- 
Gruss, Joerg