[Asterisk-Dev] A few driver ideas...

[Hans Petter Selasky]

On Thursday 05 January 2006 15:49, kpj at junghanns.net wrote:
> >> > 1. zaptel wrapper for mISDN. Would this add any value to anyone?
> >
> > I've
> >
> >> > had a look around in the code for both drivers and it doesn't seem
> >
> > too
> >
> >> > impossible...
> >>
> >> What should that look like and what should it do? mISDN handles the
> >> complete protocol stack in the kernel but zaptel is just a stupid
> >
> > layer 1
> >
> >> device...
> >
> > Ah. That makes some sense. So where is the protocol stack handled if
> > zaptel is doing layer 1? Userspace?
>
> Yes, libpri is handling the signalling in userspace. It has the big
> advantage that you can make modifications to the stack without risking to
> blow up your whole kernel.

I don't think that it is a good idea to write a specialized harware driver for 
Asterisk. There are more telephony solutions in the world than Asterisk, and 
really the API of the Asterisk channel drivers, is not the best I have seen:

- It creates one thread for each call. 

- It is does not have a proper locking model.


And what happens if you want to run two telephony solutions? When asterisk 
crashes, your whole telephony system is gone, so really moving things out of 
the kernel does not help, with regard to keeping your telephony service up.


> > Also debugging signalling problems in userspace is
> > much quicker than in kernelspace.

Sure it is easier to do testing in userland, but then the kernel should 
provide the application with a device that gives direct access to the 
D-channel / B-channel instead. zaptel/zaphfc should then open these devices. 
In my ISDN driver for BSD, see http://www.turbocat.net/~hselasky/isdn4bsd, 
there is "/dev/ihfcX.Y".

X=0,1,2,3... : controller unit

Y=0: D-channel
Y=1: B1-channel
Y=2: B2-channel

These devices were only intended for debugging, but it is not a big deal to 
extend their usage.

> >
> >> > 3. zaptel driver for the 'netjet' PCI BRI adapter (one of the few
> >> available in Australia, and by far the cheapest). There is an

I have seen that there is sometimes a problem with the ones using an AMD c/o 
chip, during boot, but else not. These cards work fine, and most likely any 
trouble is due to bugs in the driver. I typical bug is to think that read DMA 
counters are stable when they are not, and to forget to apply range checks.

>
> I am not familiar with the Tigerjet chipset. Can you get a 1khz timer out
> of it? If yes, a zaptel driver is possible.

The ISAC chips have something called SIN, that can interrupt every 1.5ms.

HFC-S XXX chips can interrupt every 125us, by enabling the BUSY/NON-BUSY 
transition interrupt.

But even if one is moving data at a fixed clock, one still has to 
strech/compress the sound, when bridging ISDN to ISDN, in software. It is 
because different networks can have slightly different transfer rates, due to 
not having a common clock source. In other words: ISDN is best switched in 
hardware, using cables.

When it comes to porting hardware drivers to other platforms, I think it is 
better to spend some time on writing a kernel emulator, for the platform one 
is planning to port a driver to, than to fork off a completely new driver. 
Here is a FreeBSD kernel emulator for NetBSD. It supports PCI devices:

http://www.turbocat.net/~hselasky/isdn4bsd/sources/module/

--HPS