From owner-freebsd-hackers  Tue Oct  1 18:02:06 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA16937
          for hackers-outgoing; Tue, 1 Oct 1996 18:02:06 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA16931
          for <hackers@freebsd.org>; Tue, 1 Oct 1996 18:02:02 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id UAA21968; Tue, 1 Oct 1996 20:00:45 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199610020100.UAA21968@dyson.iquest.net>
Subject: Re: isdn code
To: michaelh@cet.co.jp (Michael Hancock)
Date: Tue, 1 Oct 1996 20:00:45 -0500 (EST)
Cc: terry@lambert.org, phk@critter.tfs.com, hackers@freebsd.org
In-Reply-To: <Pine.SV4.3.93.961002090602.1243A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Oct 2, 96 09:14:58 am
Reply-To: dyson@freebsd.org
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> On Tue, 1 Oct 1996, Terry Lambert wrote:
> 
> > > The Teles driver only supports HDLC and does not support PPP, though I
> > > think they are working on PPP support.  I think most FreeBSD Teles Users
> > > in Germany prefer HDLC because it has less overhead than PPP, so most of
> > > the effort goes there.  This doesn't help for those who need to connect to
> > > other vendors devices that are most likely use PPP.
> > 
> > Sounds like a situation where you'd want to say "American, if you want
> > support, write it", not "German, we are going to drop your driver unless
> > you support American hardware and protocols".
> > 
> > Sound like the code isn't being Americanized; that's far different than
> > it not being maintained.
> 
...
> ATT, NT, NTT, EuroISDN, etc. 
> 
> The communications gurus tell me that it really isn't that difficult to
> provide support the for various interfaces.
> 
It is somewhat true if you are just sending data.  Hopefully, someday,
we would support sophisticated call control features.   Imagine a device
that can INTEGRATE data and voice seamlessly.  The call control features
(above Q931) is where the differences become significant.

John