[Asterisk-Dev] More Zaptel/BRI questions

[James Harper]

> > 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.

This is in the bri-stuffed by tracking system? Or somewhere in the
zaptel tarball?

When you say 'D-channel messages', I assume you are talking about the
bits on the line having been 'cooked' into the different types of
message? Or is a 'D-channel message' in this context just a fixed group
of bits?

>
> 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.
> 

I don't think I'm up to speed enough yet to fully comprehend the
above... but I'll have a go at paraphrasing it and maybe you can let me
know how I go?

B channels: I can just get the bits from the card and give them to
zaptel, and get the bits from zaptel and give them to the card.

D channel - option 1: Zaptel knows how to manipulate the D channel at
the bits level (is this what HDLC is about, or is that just decoding the
raw BRI bits on the physical line?). Give zaptel the raw bits from the D
channel and have it do all the processing. As far as my driver is
concerned, it's just another data channel. All my driver has to do is
pass raw bits back and forth between zaptel and the hardware.

D channel - option 2: (not sure about this one) Don't tell zaptel about
the D channel, when zaptel wants to do something with the line (via a
callback???) my zaptel driver does all the D channel processing itself.
Obviously more complicated than #1.

D channel - option 3: For an (semi?) active card (which my card is not),
don't tell zaptel about the D channel. When zaptel wants to do something
with the line, use the higher level D channel functions in the card to
do things with the D channel.

Thanks for the response.

James