Date: Fri, 15 Jul 2005 01:05:15 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: twinterg@gmx.de Cc: freebsd-isdn@freebsd.org Subject: Re: Problem with C4B on FreeBSD-Stable Message-ID: <200507150105.17378.hselasky@c2i.net> In-Reply-To: <42D6D22E.9010202@nord-com.net> References: <7112CBFA-724E-4846-AA2E-1EFBC4B49CE2@cian.ws> <200506210044.00616.hselasky@c2i.net> <42D6D22E.9010202@nord-com.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 14 July 2005 22:59, Thomas Wintergerst wrote:
> Hi Hans Petter,
>
> Hans Petter Selasky wrote:
> > On Sunday 19 June 2005 11:18, Thomas Wintergerst wrote:
>
> [...]
>
> Maybe your i4b-CAPI driver could register its
> passive controllers at the CAPI manager. Then all applications like
> Asterisk could use any controller type through a single interface
> specification.
I'll have to take a closer look at C4B before I can say if this is possible.
There are some problems like that "i4bcapimgr" must be disabled for passive
devices, hence these devices are already sending signals to /dev/i4b.
My model is like this:
Active <-->-+ +- /dev/i4b
+ ---- common ----+
Passive <-->-+ +- /dev/capi20
Thomas' model is like this:
(x) <--> + +- /dev/i4b
+ ---- common ----+
Passive <--> + +- /dev/capi20 --+
+- /dev/capi20
Active <--> (x) ---- direct ---- --+
(x) i4bcapimgr
I thought that active CAPI controllers could register under I4B using the
following functions:
i4b_controller_allocate
i4b_controller_free
i4b_controller_attach
i4b_controller_detach
Then we upgrade "i4bcapimgr" so that functionality is not lost. This will mean
introduction of new signals. All information is transferred through the call
descriptor structure (see struct call_desc), which must be extended.
Sometimes information will be stored in a CAPI friendly fashion, and other
times I4B friendly.
Because later we might add fax/modem emulators and other protocols that run
between "Layer 1" and what I call "Layer 5", and if the CAPI firmware does
not support that, there is no way that the CAPI interface can support those
protocols, if we use a direct CAPI to CAPI bridge.
But how is performance related NCCI/PLCI lookup. Do you have to do a linear
search each time you receive a data-b3-indication to decide to which
"/dev/capi20.XX" the frame should go?
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507150105.17378.hselasky>