HDTenEightyP/NetNews huggingface dataset:
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: isdn "supermodem"
Organization: Gandalf Data Ltd.
Distribution: na
Date: Mon, 25 Jan 1993 14:44:47 GMT

In <1993Jan22.160035.7443@sifon.cc.mcgill.ca> rob@polestar.facl.mcgill.ca (Robert Macfarlane) writes:

>Here's an arrangment I would like to see:

> customers      | POTS |          C.O.        | ISDN link |  my house

>  end user modem ------ modem --|-------------|
>  end user modem ------ modem --|             |
>  end user modem ------ modem --| multiplexer |         +---------------+
>  end user modem ------ modem --|             |=========| my BBS server |
>  end user modem ------ modem --|             |         +---------------+
>  end user modem ------ modem --|-------------|

>I don't see how we could eliminate the modems, but we should be able to  
>move them to the c.o., and have only one 2B+D line from the c.o. to the  
>host, no?

>Does anybody know what one would need to put in my box labelled  
>'multiplexer?'  

How about a multiplexer!!  Statistical or X.25 multiplexer to be precise.
You would need TA's to go over the ISDN, but this can be done with
todays equipment.  
 
>Of course, we would also need some sort of demultiplexing  
>ISDN software/hardware in the host.  In theory, one should be able to  
>multiplex 8 v.32bis lines (8 x 14.4 = 115.2) into one 2B+D connection.   

Actually, you should be able to handle 16 or more channels over 2B+D.
Statmuxes and PADs (X.25 mux) handle the contention.

Call our Montreal office and talk to a FAE.

Newsgroups: comp.dcom.isdn
From: toense@cplxsys.ncsl.nist.gov (Robert E. Toense)
Newsgroups: comp.dcom.isdn
Subject: Re: 23B+D (PBX) & 2B+D (Home)
Date: 21 Jan 93 15:17:46 GMT

In article <727133341snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
|> In article <C0n63t.GBM@norstan.com> sfrazier@norstan.com writes:
|> 
|>    Would the following work?
|> 
|>    Install a 23B+D T1 into an ISDN compatible PBX from the local Telco.
|>    From the local telco install 23 2B+D to 23 individual homes.
|> 
|>    Anyone, please comment if the above would or wouldn't work.
|> 
|> If it works, it's definitely illegal.
|> 
|> -russ <nelson@crynwr.com> What canst *thou* say?
|> Crynwr Software           Crynwr Software sells packet driver support.
|> 11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
|> Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

Not only will it work, that is one way that it is supposed to be used.  The T1 is
actually an ISDN PRI.  Better yet, it doesn't matter how many homes you want
to communicate with.  The issue is capacity management.  If the 23 Bs are busy,
the call will be rejected.  Just like the problem you have calling your mother
on Mother's Day with today's POTS service.

Robert E. Toense
National Institute of Standards and Technology (NIST)
(toense@cplxsys.ncsl.nist.gov)
From: imhw400@indyvax.iupui.edu
Newsgroups: comp.dcom.isdn
Subject: Re: isdn "supermodem"
Date: 23 Jan 93 09:49:38 -0500

In article <1993Jan22.160035.7443@sifon.cc.mcgill.ca>, rob@polestar.facl.mcgill.ca (Robert Macfarlane) writes:
> Here's an arrangment I would like to see:
> 
>  customers      | POTS |          C.O.        | ISDN link |  my house
> 
>   end user modem ------ modem --|-------------|
>   end user modem ------ modem --|             |
>   end user modem ------ modem --| multiplexer |         +---------------+
>   end user modem ------ modem --|             |=========| my BBS server |
>   end user modem ------ modem --|             |         +---------------+
>   end user modem ------ modem --|-------------|
> 
> I don't see how we could eliminate the modems, but we should be able to  
> move them to the c.o., and have only one 2B+D line from the c.o. to the  
> host, no?

The telco will be most pleased.  They can make money from that modem bank. 
Keep an eye on them, to make sure that they plan to charge the right person.

> Does anybody know what one would need to put in my box labelled  
> 'multiplexer?'

You won't like the answer.  Nobody ever does.  Inside the "multiplexer" box is
the X.25 packet handler.  Since your end users seem to be async. terminal
types, put a PAD there as well.  {Sound of hundreds of readers making signs
against the Evil Eye.}

When your customers cut over to ISDN, the modems and the PAD are bypassed but
the PH is still there.  The customers supply their own PADs.  {Chanting becomes
audible.}
--
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.
Newsgroups: comp.dcom.isdn
From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Organization: W S Rupprecht Computer Consulting, Fremont CA
Date: Fri, 22 Jan 1993 05:48:10 GMT

>Maybe bridging is the right answer for Appletalk, OSI, and so on.  In
>some cases, bridging may make sense for IP.  But bridges are not a
>universal solution.

Not to start a war or anything, but I'm curious why do folks build
bridges as opposed to routers.  Is it to save the cost of writing the
code to do the TCP/IP hacking or is it that they would need much more
hardware to support the computional horsepower needed to unravel the
upper level protocol and then wrap the data-packet back up?

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511
From: burress@twics.co.jp (Tim Burress)
Newsgroups: comp.dcom.isdn
Subject: INS-64 TA and TA+MODEM in a box?
Date: 26 Jan 93 13:03:19 GMT
Organization: TWICS, Tokyo, Japan

Does anyone have recommendations for terminal adapters to be used with NTT
INS-64? 

Also, does anyone make some kind of "TA+MODEM in a box" device?  We run a
public-access dialup service in Tokyo, and the current plan is to connect each
B-ISDN line to a terminal adapter that outputs analog, then run the two analog
lines into modems where they'll be converted into serial data for our host
ports.  But it seems kind'a silly to convert from digital to analog to digital
again, so I wondered if anybody has combined the two functions in one box. 

Or is there a better way???

						Thanks!

-- 
Tim Burress                                     Internet:  burress@twics.co.jp
TWICS Co., Ltd.
1-21 Yotsuya, Shinjuku-ku, Tokyo 160 Japan
Newsgroups: comp.dcom.isdn
From: ckd@eff.org (Christopher Davis)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Organization: Electronic Frontier Foundation Tech Central
	<v738b2c@rhyolite.wpd.sgi.com>
Date: Fri, 22 Jan 1993 20:57:18 GMT

VS> == Vernon Schryver <vjs@rhyolite.wpd.sgi.com>

 VS> Back to the original thread, most of us don't want to buy an ISDN
 VS> bridge.  I think few of us want to forward Appletalk or any protocol
 VS> other than IP over our ISDN links.  Most of us want a simple, cheap IP
 VS> router, probably one that does compression to make 64Kb seem less
 VS> slow.

And if we do decide to forward AppleTalk or some other protocol, we'll
either spend the extra money for a multiprotocol router, or we'll
encapsulate it in IP like we already do to get it across IP-only backbones.

 VS> If the established (hardware) companies don't build one, then history
 VS> will repeat itself.  Remember that Telebit and cisco started (I think)
 VS> as largely software efforts.  Now "brouters" are common and all modems
 VS> have lots of software.

I wholeheartedly agree with the preceding paragraph.
--
 * Christopher Davis * <ckd@eff.org> * <ckd@kei.com> * [CKD1] * MIME * RIPEM *
Newsgroups: comp.dcom.isdn
From: "Michael Smith" <p00004@psilink.com>
Subject: Q's on ASI interface for ISDN TAs
Organization: Performance Systems Int'l
Date: Thu, 28 Jan 1993 21:04:14 GMT
X-Mailer: PSILink-DOS (3.3)

Hope this isn't a FAQ (at any rate, it's not in the file).

I've been trying to read the Application Software Interface (ASI) spec 
from the N American ISDN Users' Forum, and I find that I'm quite puzzled 
by what would seem to be elementary aspects of it. If somebody out there 
can set me straight, I'd be most grateful.

1) Does the spec provide an interface for the transfer of user data to 
the remote user and vice versa, or is it only for device control and 
call setup? There's a permissible value for "User Plane" in the 
"Protocol Identifier" field of the header, so presumably applications 
can send stuff to the user plane; I can't imagine what else would 
reasonably happen to data on the user plane except to be sent to the 
remote user and passed to it across its user plane, but on the other 
hand no message types for the user plane are defined and there isn't any 
explicit discussion of data transfer anywhere in the document, as far as 
I can tell. 

2) Is it envisioned that any Level III or Level II protocols besides 
those associated with call control on the D-channel will live below the 
ASI interface (i.e. on the adapter driver side of it)? The spec says 
that the interface is envisioned as existing at the Level IV to Level 
III interface. And there are all these control blocks for various types 
of connections (clear channel, V.120, X.25 to the remote end or a PSDN, 
etc.) But are these provided only as a way of getting information to 
the Q.931 implementation so that it can use the information in call 
setup? Or are they intended to make connection parameters available to 
V.120, X.25, etc. protocol implementations below the ASI?

Thanks in advance to any Good Samaritans who can lend a hand.

--Michael Smith

Newsgroups: comp.dcom.isdn
From: tcain@brtph87.bnr.ca (Tom Cain  WB8OUE)
Subject: Re: Protocol analyzer PC card
Reply-To: tcain@bnr.ca
Organization: BNR Inc. RTP, NC
Date: Tue, 26 Jan 1993 18:54:19 GMT

In article <C17nJB.I9r@vptt.ch> boogman@vptt.ch (Jan Boogman vt6) writes:
>I'm preparing an integrated test environment for testing the load 
>performance of digital PABXs. To monitor the protocol on PRI and BRI (at S- 
>and T-reference point) I need protocol monitors and I'm looking for a PC- or
>preferrably Mac-based solution. Until now I heard of only *1* product that 
>suits our needs (HP 4957PC , but only PC). As I mentioned above, I prefer the
>Macintosh, so: 
>
Check out the ISDN Tel/Scope from Progressive Computing (now part of
Network General).  It does not run on a mac, but, an ISA bus machine.
I have one in a Toshiba 3200 and love it!  Add PC-Anywhere to the analyzer
host machine and it makes a great remotely accessable analyzer.
-- 
Tom Cain  WB8OUE                             tcain@bnr.ca
disclaimer: i don't speak for nobody!
From: madigan@myrtle.stat.washington.edu (David Madigan)
Newsgroups: comp.dcom.isdn
Subject: PC Libraries for Remote Control
Date: 25 Jan 93 20:32:50 GMT
Article-I.D.: shelley.1k1ipiINNrt8
Organization: Univ of Wash , Stat Dept.
NNTP-Posting-Host: myrtle.stat.washington.edu

Newsgroups: comp.dcom.isdn
Subject: PC Software Libraries for Remote Control ISDN
Summary: 
Expires: 2.10.93
Followup-To: 
Distribution: h
Organization: Univ of Wash , Stat Dept.
Keywords: ISDN, Software Libraries

I'm looking for software libraries (ideally DLL's with source code)
for a remote control ISDN application for use on MS Windows PC's.
In particular, we want to transmit keyboard inputs and mouse information
toa distant PC and receive the resulting graphics display information
(VGA) from the distant PC.

David Madigan
madigan@stat.washington.edu
Newsgroups: comp.dcom.isdn
From: nisimura@sran233.sra.co.jp (Tohru Nishimura)
Subject: Re: Subaddressing (was: ISDN/analog interfacing)
Organization: Software Research Associates, Inc., Japan
Date: Wed, 27 Jan 1993 15:17:21 GMT

ketil@edb.tih.no (Ketil Albertsen,TIH) writes;

> If there is any way that the exchange can detect which functionality
> my PC-with-ISDN-card realizes in its software, then I haven't read the
> ISDN recommendations close enough.

You are right in some sense.  To work correctly is responsible for TE. 
Without telcom certification no equip can be sold/usedsold in Japan.
From my observation, ISDN NT1 is just a I-interface DSU with little
intelligence.  Dialogues by ISDN exchange is enssential.

- nisimura
From: Kevin.Kershaw@StPaul.NCR.COM (Kevin Kershaw  )
Newsgroups: comp.dcom.isdn
Subject: Re: BONDING and T1 Letter Ballot
Keywords: BONDING,ISDN
Date: 25 Jan 93 16:39:01 GMT
Organization: NCR NPG, St. Paul, MN


Thanks to all who respoded to my inquiry on BONDING and T1 Multi-
rate capability.  Your information has been very helpful.  
As a follow on issue, I would be interested in obtaining more
information on the BONDING protocols.  I am currently supervising
a development that provides both BRI and PRI support for devices
attached to our line of communications processors.  We have
implemented a proprietary end-to-end protocol between our own
devices that allows multiple B-channels to be brought into
service to increase the end-to-end bandwidth.  This capability is
dynamic (channels are brought into and out of service as needed)
and can span channels on combinations of BRI and PRI interfaces. 
This product was designed almost 2 years ago so the BONDING work
was unknown to us at that time.  I would like examine whether it
makes sense for us to move to BONDING in future releases. Does
anyone know where I might obtain the specs for the BONDING
procedures?

Secondly, in response to  
>ketil@edb.tih.no (Ketil Albertsen,TIH)

who stated 

>I don't think it is essential to provide 3B, 4B, 5B,...29B -
>after all, we manage with modem speeds in doubling steps, and
>with TDM channels in quadrupling steps (in Europe - US is more
>irregular), with no one claiming that eg. a 7200 baud modem
>standard would "increase flexibility", now that we got 4800 and
> 9600.

The big difference with ISDN on this point is that you are going 
to pay your service provider for each additional channel you
bring on line.  If you are running 2 B already (128K) and another
64K on line will cover your needs, why pay for another 128K?

Also, always doubling gets a bit crazy when we get to future
networking speeds.  "Hello Mr. Salesman, I've got a 1 Gig pipe
full now and I'm bringing another user on line next week.  Better
put me down for another Gig on Monday";-). 

Kevin Kershaw                              DAMN IT'S COLD OUT......
NCR Network Products Division
St. Paul, MN.
Newsgroups: comp.dcom.isdn
From: scott@labtam.labtam.oz.au (Scott Colwell)
Subject: Re: BONDING and T1 Letter Ballot
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Wed, 27 Jan 1993 02:48:36 GMT
Keywords: BONDING,ISDN

cstorry@gandalf.ca (Chuck Storry) writes:
>There are other "standards" in addition to BONDING to consider (or perhaps
>not). They include CCITT H.221 and I belive that Australia has one.

The Australian standard referred to is AS 4046-1992 "Information Processing-
Digital channel aggregation (n x 64)". There is also a draft standard for
comment out at the moment which proposes some enhancements to the above
standard and some refinements to clarify interpretations of it.

It is simpler than H.221.  The enhancements are related to providing a
signaling channel based on HDLC and providing error performance
monitoring for recovery of 'bad' channels etc.

>(For those not in the know BONDING consists of 4 modes:
>mode 0 - inband negotiation (no B channel aggregation)
>mode 1 - inband negotiation , channel equalization and subsequent aggregation
>         (but no monitoring for loss of sync and no end-end com channel)

Basic AS 4046 provides this plus sync detection and recovery.

>mode 2 - mode 1 and overhead framing to determine synchronization status
>         and an end-end communication channel in order to dynamically
>         add and remove channels (and maintenance : loopback, etc)

Pretty much what is in the draft proposes.  (DR92238:S)

>mode 3 - as per mode 2 but bnadwidth is added in 8k increments rather than 
>         "B" channel (56/64k) increments.

???  I agree with Chuck !  Who wants this?
-- 
Scott Colwell				Labtam Australia Pty. Ltd.
net:	scott@labtam.labtam.oz.au	41 Malcolm Rd., Braeside
phone:	+61-3-587-1444			Melbourne, Australia  3195
Xref: sparky comp.dcom.servers:203 comp.sys.sun.admin:10828 comp.sys.sun.hardware:7149 comp.sys.sun.misc:6553 comp.sys.sun.wanted:2237 comp.periphs.scsi:6740
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Newsgroups: comp.dcom.servers,comp.sys.sun.admin,comp.sys.sun.hardware,comp.sys.sun.misc,comp.sys.sun.wanted,comp.periphs.scsi
Subject: Re: I need more serial ports!! (Sun ELC)
Date: 28 Jan 93 00:36:18
Organization: TH-Darmstadt
Distribution: world
NNTP-Posting-Host: pdv2.fmr.maschinenbau.th-darmstadt.de
In-reply-to: lra@caribou.Eng.Sun.COM's message of 27 Jan 1993 10:43:41 GMT


....BUT a SUN has an ethernet interface. How about attaching a 
common terminal server to it. Should be dable for 1000 US$/8lines.

best, adams
Xref: sparky comp.dcom.servers:204 comp.sys.sun.admin:10845 comp.sys.sun.hardware:7159 comp.sys.sun.misc:6562 comp.sys.sun.wanted:2240 comp.periphs.scsi:6749
From: lra@caribou.Eng.Sun.COM (Larry Ader)
Newsgroups: comp.dcom.servers,comp.sys.sun.admin,comp.sys.sun.hardware,comp.sys.sun.misc,comp.sys.sun.wanted,comp.periphs.scsi
Subject: I need more serial ports!! (Sun ELC)
Date: 27 Jan 1993 10:43:41 GMT
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
Distribution: world
Reply-To: lra@caribou.Eng.Sun.COM (Larry Ader)
NNTP-Posting-Host: caribou
Originator: lra@caribou


I have a Sun ELC at home and am in desperate need of more serial ports.
For those of you who are unaware, the ELC has two (actually 1.5 8-)) serial
ports on the back of it, and NO S-Bus slots.  I have several devices hooked
up to these ports now.  I have one dedicated port for my modem, and I am
multiplexing three other devices on the other port (printer, X10 serial
interface, and PC downlink line) using a (manual) switchbox.

To me, this solution is not elegant (or convenient).  What I'm wondering,
is what others of you have done when you ran out of serial ports.  I have
heard of terminal servers and am wondering how well these work.  Do you
have any recommendations?  I obviously need something that attaches over
ethernet or the SCSI bus.

Keep in mind that this device would be purchased by myself (for home use),
and as such, I would like to keep the costs as low as possible (<$1000?).


Any suggestions would be greatly appreciated...

Larry Ader

-------------------------------------------------------------------------
 Larry Ader                         || 
 Sun Microsystems, Inc.             ||
 2550 Garcia Ave.  M/S  MPK03-201   ||  lra@caribou.sun.com   (work)
 Mountain View, CA   94043-1100     ||  ..!amdahl!echidna!lra (home) 
   ph. 415/688-9721                 ||
   or 1-800-435-7001  x49721        ||
-------------------------------------------------------------------------

Newsgroups: comp.dcom.servers,comp.sys.sun.admin,comp.sys.sun.hardware,comp.sys.sun.misc,comp.sys.sun.wanted,comp.periphs.scsi
From: adh@cbnews.cb.att.com (andrew.d.hay)
Subject: Re: I need more serial ports!! (Sun ELC)
Organization: guess
Date: Wed, 27 Jan 1993 16:07:55 GMT

lra@caribou.Eng.Sun.COM (Larry Ader) writes:
"
"I have a Sun ELC at home and am in desperate need of more serial ports.
[]
"To me, this solution is not elegant (or convenient).  What I'm wondering,
"is what others of you have done when you ran out of serial ports.  I have
"heard of terminal servers and am wondering how well these work.  Do you
"have any recommendations?  I obviously need something that attaches over
"ethernet or the SCSI bus.

not necessarily.  it's hardly any cheaper, but you can run x.25 over
the serial ports [sun has a driver] into a pad [packet
assembler/disassembler] with asynch. serial ports -- i've seen pads
with 8 and 16 lines...

in general, i think you'll find meeting your price goal quite
challenging.	;^<

-- 
		+--------------------------------------------------------------+
Andrew Hay	|	one step beyond the outer limits of the twilight       |
a_d_hay@att.com	|	zone in the darkened room at the night gallery	       |
		+--------------------------------------------------------------+
Newsgroups: comp.dcom.servers
From: foxworth@bnlux1.bnl.gov (Bob Foxworth)
Subject: Can a server output to serial line?
Organization: Brookhaven National Laboratory, Upton, NY 11973
Date: Fri, 22 Jan 1993 20:11:39 GMT


We have a Xyplex Maxserver 4500 containing two MX2120A 8-port
terminal server cards. Right now I have them wired to ports on a data
PBX linecard which are configured as a destination class, so that a user
of the data PBX can select 'xyplex' as a destination, and then reach
one of the Xyplex's serial ports which is acting as an input. Then the
user reaches the network to do a LAT or telnet connect to wherever. They
are DTE and the PBX is using a DCE type fanout cable to its line card.

Someone here has asked about the possibility of creating a destination
in the xyplex, other than getting onto the ethernet. This destination
would have to reach a serial input on an old DG computer, running at
9600 bps, and would, it seems require reconfiguring a serial port on
the xyplex as a destination and then hardwiring it to the DG serial
input. I don't know of any way to (1) specify a destination inside
the xyplex, other than the network, or (2) reconfigure a serial port
on a individual basis. Doing this would allow someone calling the
xyplex from the PBX to then log onto the DG at 9600 bps, bypassing
the ethernet side of the interface entirely.

The functionality the requester wants is to be logged onto a workstation
somewhere in the facility, telnet to the xyplex over the network and
then come out of it, onto a serial line and reach the DG input. This
would let someone work on the DG from locations with no PBX service.

The PBX already reaches the DG serially, but that isn't helping me in my
debate with the person who wants the xyplex hookup, so I need to come
up with some real data on it's feasability. I have looked at the book
to some degree, but no luck there.

As an aside, the xyplex supports standard rs-232 pins 2,3,7,8,20 and
22 and the DG interfaces are 2,3,4,5 and 7. So handshaking could become
really interesting. I believe it can't be done but would like to have 
either confirmation or enlightenment. Please either post to the group 
or email me any thoughts on the possibility of doing this, many thanks.

Bob Foxworth

Newsgroups: comp.dcom.servers
From: rkh@ucs.att.com (Bob Halloran)
Subject: Info-annex location, and Annex log digester?
Organization: AT&T Universal Card Services, Jacksonville FL
Distribution: na
Date: Mon, 25 Jan 1993 21:56:01 GMT

Someone had mentioned a script some time ago to summarize
the Annex's acp_logfile.  Is this available somewhere?  Also,
where is the info-annex list kept?  Thanks in advance.

	Bob Halloran
	AT&T Universal Card
	Jacksonville FL

	rkh@ucs.att.com
Any similarity between opinions stated here and AT&T's 
  corporate opinion are purely coincidental.

"When the going gets weird, the weird turn pro." - Hunter S Thompson
Xref: sparky comp.dcom.servers:195 comp.dcom.lans.ethernet:3046
From: gale@cps.msu.edu (Kristopher W Gale)
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
Subject: Re: Switching from 3+Share 1.3.1 to LANMAN 2.1 impressions (long-ish)
Keywords: 3Share 3Com LANMAN Microsoft
Date: 21 Jan 93 04:26:06 GMT
Reply-To: gale@cps.msu.edu (Kristopher W Gale)
Organization: Dept. of Computer Science, Michigan State University
NNTP-Posting-Host: atlantic.cps.msu.edu
Originator: gale@atlantic.cps.msu.edu


TEST
-- 
Kris Gale				
(gale@cps.msu.edu)			"It's only a flesh wound."
126 E Wilson					-- Black Knight
E.Lansing, Mi. 48825				   Search for the Holy Grail