Date: Wed, 8 Mar 2000 10:21:37 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: hm@hcs.de Cc: freebsd-isdn@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing) Message-ID: <200003081821.KAA59436@bubba.whistle.com> In-Reply-To: <20000308110649.3674A3A34@hcswork.hcs.de> from Hellmuth Michaelis at "Mar 8, 2000 12:06:48 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Hellmuth Michaelis writes: > > 2. We should come up with a 'standard' netgraph control message > > API for an ISDN basic rate interface, and have i4b implement > > this interface. Then mpd/ppp/etc can "know" this interface > > and therefore work automatically with any ISDN BRI device. > > Here is the interface that we use at Whistle: > > ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h > > (note: the switch types are #defined in another file but include > > all of the usual suspects: ETSI, NI-1, AT&T, DMS100, etc.) > > The problem here is, that the Whistle ISDN stack has a fundamentally > different view of the world than i4b has :-) As far as i understood it, > the Whistle ISDN stack is almost completely configurable by using > netgraph messages whereas i4b is configured by its isdnd config file. > > I have made some experiments with mppd over the i4b netgraph b-channel > interface and it works beautifully here without any additional > configuration messages necessary. But i have no idea, if the real world > demands some control messages, such as dial, dial a number, hangup etc. Yes, our way of doing things was of course designed for our particular application. It depends on what you want to do with an 'ISDN node'. The /dev/i4b interface is actually pretty close to equivalent to our netgraph control message API. The main differences seem to be: - Our API is strictly limited to ISDN operation, e.g., there are no equivalents to I4B_TIMEOUT_UPD, I4B_UPDOWN_IND, or MSG_IDLE_TIMEOUT_IND and no connection to sppp(8) - Our API allows more ISDN-related configuration, e.g., changing switch type. - Our API is at a slightly higher level.. we don't have the CDID_REQ or PROCEEDING_IND messages; when rejecting a call, you don't get to specify the cause code, it's always set to 21 for you, etc. So the /dev/i4b and our netgraph API are actually quite similar. Of course, a major difference is that with /dev/i4b you don't get the B-channels exposed as netgraph node hooks, which is very useful... but as you've shown already this is easy to add. This gets you a "half netgraphified" ISDN node. One thing that would be easy to do is to simply convert all of the /dev/i4b ioctl's directly into netgraph control messages. This doesn't really buy you anything much though -- really just a different interface for the same thing. But if there were future plans to do all kinds of wacky things with an ISDN device that would benefit by having it fully netgraphified, maybe this would be worth doing. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003081821.KAA59436>