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
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
