Date: Thu, 9 Nov 2006 08:35:39 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-isdn@freebsd.org Subject: Re: ISDN4BSD / ihfc0 in NT-mode setup Message-ID: <200611090835.39728.hselasky@c2i.net> In-Reply-To: <20061108204201.GF6819@insomnia.benzedrine.cx> References: <20061108135555.GK14033@insomnia.benzedrine.cx> <200611081927.57954.hselasky@c2i.net> <20061108204201.GF6819@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611090835.39728.hselasky>