Date: Sat, 28 May 2005 15:34:56 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-isdn@freebsd.org Cc: Steven Looman <steven@krx.nl> Subject: Re: Asterisk on FreeBSD + ISDN BRI Message-ID: <200505281534.58499.hselasky@c2i.net> In-Reply-To: <DABECAF6-58C5-4F46-8C61-F71DBD12E675@cubical.fi> References: <20050526202222.E2BD81EAE291@alice.turbocat.de> <20050527140607.GA41449@minerva.krx.nl> <DABECAF6-58C5-4F46-8C61-F71DBD12E675@cubical.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 27 May 2005 16:21, Juha-Matti Liukkonen wrote:
> Hi,
>
> back in the day when I wrote the AVM active card support to i4b, I
> fantasized about pulling the capi layer up as the kernel-userland
> interface instead of i4b_layer4; this would have meant implementing a
> capi-specification-compliant (and AFAIK linux-compatible) /dev/capi20
> and rewriting isdnd to use it instead of the current i4b* devices. A
> good part of the necessary support code is already present in the
> capi layer (i4b layer4 only registers as one client application for
> the somewhat-more-generic capi layer).
>
> Passive card support would have meant writing a "capi link-layer
> driver" (a la capi_iavc for the AVM isdn chipsets) for the i4b
> passive stack, which hosts the existing passive card drivers. Didn't
> seem an insurmountable task at the time. Re-doing isdnd, on the other
> hand, did seem like somewhat of an effort.
>
> I'm not sure what the relevance of this design is any more,
> considering that c4b is sort-of doing the same thing, but this way
> it'd be reasonably easy to provide a CAPI interface for all i4b-
> supported passive cards.
I know that Windows uses CAPI to support ISDN devices, but the problem there
is that only one ISDN device is allowed at a time. So can CAPI handle more
than one physical device per CAPI interface (/dev/capi20) ?
>
> On 27.5.2005, at 17.06, Steven Looman wrote:
> > Or how about writing a capi emulation layer on top of the CAPI
> > interface?
> > Don't know if this is possible at all, since there can be timing
> > issues?
This shouldn't be so difficult. One just has got to number the consumers,
for example /dev/i4b0, /dev/i4b1, /dev/i4b2 ... Then the cdid
(call-descriptor-ID) will be shared among all interfaces. When sending
messages to these devices then two modes have got to be supported: Broadcast
and peer-to-peer. A function, cd_set_consumer(), decides whether a given
call-descriptor (cd) receives/transmits broadcasted or peered messages. By
default broadcast is selected.
Then an incoming call will look like this:
cd_set_consumer(cd, NULL);
i4b_l4_connect_ind(cd);
...
case I4B_CONNECT_RESPONSE:
c1 = consumer-pointer of the device that
received the message;
if(cd->consumer == NULL ||
cd->consumer == c1)
{
while((c2 = ...)) {
if(c1 != c2) {
cd_set_consumer(cd, c2);
i4b_l4_disconnect_ind(cd);
}
}
cd_set_consumer(cd, c1);
N_CONNECT_RESPONSE(...);
}
...
Something similar to this is done to allow the DSS1 protocol to operate in
NT-mode. Though one has got to put a limit on the number of consumers, for
the sake of speed. I guess that "consumer" is called AppletID in CAPI?
After this transition is done, one can just put a packet converter on top of
one of the /dev/i4bN devices to get a CAPI device?
> > The ability to use CAPI with cheap cards (like in Windows for
> > example) sounds
> > great as it would be easier to write multiplatform applications.
I don't think that CAPI is fit for every situation. Putting things in a
library on top of "isdnd" is going to be much more powerful than if one
writes a dedicated CAPI-compatible telephony application?
What kind of applications are we talking about porting?
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505281534.58499.hselasky>