Skip site navigation (1)Skip section navigation (2)
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>