ISDN4BSD / ihfc0 in NT-mode setup

[Hans Petter Selasky]

On Wednesday 08 November 2006 21:42, Daniel Hartmeier wrote:
> 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?

There is defined a CAPI over TCP, but I don't recall the name of the standard.

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

You have to do some dispatching, else you cannot forward sound from the 
B-channels or you don't know when to forward sound from the B-channels.

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

You have to increment some refcounts first, to have Layer1 activated.

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

/dev/i4b does not have any safety timers, so if the connection breaks down, 
then you have to close /dev/i4b . Really you should check that calls are 
present regularly, say every 8 - 16 seconds.

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

How about that you use /dev/capi20. Then you make a dummy ISDN controller, 
that really outputs/reads all its frames from some /dev/isdntunX . Then you 
can keep everything in the kernel, except the frame forwarding.

--HPS