[Asterisk-Dev] More Zaptel/BRI questions

[Matthew Fredrickson]

On Jan 5, 2006, at 8:51 PM, James Harper wrote:

> My understanding of ISDN is that data is transmitted in frames of 16
> data bits (B1) + 16 data bits (B2) + 4 data bits (D) + some
> synchronisation. 4000 of these frames are received per second, which
> gives us the 16 * 4000 = 64kbps rate for the B channels and 4 * 4000 =
> 16kbps rate for the D channel. To get the zaptel timing of 1000
> interrupts/second, the card needs to be able to generate an interrupt
> off (at least) every 4th frame. If the best it could do was to generate
> an interrupt per frame, how much would that kill the system in 
> interrupt
> servicing?

That's something you'll have to investigate on a card per card basis.  
Generating a lot of interrupts in itself is not a terrible load 
intensive task; it's if you have a lot of things to do in the interrupt 
handler or for some reason you miss an interrupt (particularly if 
you're passing non-voice data) and loose data that you can have 
problems.

>
> Looking at the way some of the zaptel drivers work, this timer 
> interrupt
> is the only interrupt that is cared about, and the card is polled per
> interrupt rather than being truly interrupt driven. Or maybe I just
> haven't looked at enough drivers...
>
> Can anyone tell me what sort of pre-processing needs to be done to the
> raw data from a [BP]RI card into the zaptel driver? I assume that the D
> channel needs to be decoded from the raw bits on the line (or does
> it...?), but does the zaptel logic need anything more than raw bits 
> from
> the B channels? I'm not really familiar with PRI cards, but in the BRI
> space there are 'passive' cards, 'semi-active' card, and 'active'
> cards... can zaptel cope with different levels of processing being done
> on the card, or does it like to do it all itself? Or none of it itself?
>

Zaptel likes to just have the raw B-channel data.  If you are trying to 
also interface the D-channel with zaptel and you can pull your 
HDLC-unstuffed messages from the BRI controller, you can use the 
software API for zaptel for basically passing D-channel messages into 
the zaptel buffers the way the userland apps expect it (without having 
to go through the HDLC and other code).  If you look at bug note 5120 
(IIRC) the most recent version of the patch against zaptel can be 
found.

Due to the timing difference, (16kbps as opposed to 64kbps) this is the 
approach you'll probably want to take for the D-channel, unless you can 
think of a really clever way to pass the raw data into zaptel.

Matthew Fredrickson