ISDN4BSD / ihfc0 in NT-mode setup

[Daniel Hartmeier]

On Wed, Nov 08, 2006 at 07:27:57PM +0100, Hans Petter Selasky wrote:

> It depends on what you want to do. I would just use the CAPI 2.0 interface of 
> I4B, and extend the CAPI protocol as needed. Then your system will look like 
> this:
> 
> ISDN -> I4B <-> CAPI <-> SIP

Interfacing on Q.931 frame layer is part of the specifications I can't
change, but I'll ask if interfacing at CAPI layer would be an option.
Does CAPI define a standard for on-wire format of frames, or is it
"only" an API defining calls and arguments?

After a first glance at the kernel part of ISDN4BSD, it looks like I
could hook into the Q.931 input and output paths in

  sys/i4b/dss1/dss1_l3decoder.h

    dss1_pipe_data_ind()

      input path, after the "if(pd != PD_Q931)" check, take buf and
      dispatch it to userland. consume it, so it doesn't enter
      ISDN4BSD's L3 FSM.

  sys/i4b/dss1/dss1_l2fsm.c

    dss1_pipe_data_req()

      output path, inject frames from userland here. doesn't affect
      ISDN4BSD's L3 FSM. but doesn't trigger L2 FSM, either, is that
      a problem?

A quick hack would be use /dev/i4b, add an ioctl that enables this
behaviour, have the input path enqueue a message to be read() with a new
type, and call the output path on write() of a new type.

Do you see anything obviously wrong with this approach?

The L3 logic currently in kernel would then have to be re-done in the
userland process (decode IEs, manage a form of call descriptors, etc.)

Daniel