HDTenEightyP/NetNews huggingface dataset:
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.dcom.isdn
Subject: Develcon, on the net? any experiences?
Date: 29 Jul 1992 20:24:00 -0400
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: nigel.msen.com
X-Newsreader: Tin 1.1 PL3

I sent out a question about vendors that make ISDN products that work in
the place of modems or of CSU/DSU units.  Just got some literature in the
mail about some gear from Develcon, and I'd like to see if anyone has
experience with the product.

The unit is the Develcon "I-Gate Terminal Adaptor".  It looks to fit the
bill for the CSU/DSU replacement role, e.g.

- sync V.35 and RS232-D interface
- stored phone numbers in the unit for dedicated connections
- auto re-dial on connection drop

I didn't see anything in the glossy about them licensing the Hayes command
set, and I don't see a way to dial an arbitrary number without first
programming the modem from the front panel, so that's not quite as
flexible as you might want for a modem scheme.  But the rest of the specs
look like they fit right in for a dedicated link.

Does anyone else have one or two of these and can relay results back?  The
usual questions about how is support, sales, availability of product et
al, plus any direct experience with Internet applications.  

Phone #s (FYI) are
 +1 800 667 9333
 +1 306 933 3300 (Saskatoon, SK, Canada)
 +1 800 423 9210 (Atlanta, GA, USA)
 +1 708 452 9645 (Chicago, IL, USA; regional sales, George Bodnar)

I have no connection etc. etc. etc.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120

Newsgroups: comp.dcom.isdn
From: dave@appi.iis.u-tokyo.ac.jp (David Wuertele)
Subject: Bellcore's ADSL, AT&T's VHDSL
Organization: Institute of Industrial Science, University of tokyo.
Distribution: comp
Date: Mon, 27 Jul 1992 14:20:56 GMT

Does anybody know when (or if) ADSL or VHDSL will be available to Joe
Consumer?

-----
David Wuertele, Yasuda Lab, Electronic Engineering, Institute of Industrial Science,
University of Tokyo.				dave@windsor.iis.u-tokyo.ac.jp
Newsgroups: comp.dcom.isdn
From: rees@pisa.citi.umich.edu (Jim Rees)
Subject: Re: ISDN support for NeXT computers
Keywords: ISDN, NeXT, Hayes ISDN eXTender, 3.0
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Thu, 23 Jul 1992 21:58:29 GMT

In article <1992Jul23.150523.6634@rtsg.mot.com>, steveh@rtsg.mot.com (Steve M. Hoffman) writes:

  Basically, to date, all NeXT computers have come with a 
  Motorola 56001 DSP in addition to the main CPU (68040, 
  or '030 is you have one of the real old ones).  It was 
  originally put in for high speed number crunching, CD 
  sound, etc.  There are many more applications than I 
  can come up with since I don't normally use it.  Anyway, 
  there's an external port for the DSP availale that Hayes 
  and NeXT have developed an ISDN box (once codenamed 
  "babblefish", now called the Hayes ISDN eXTender).  
  Since the computer already has the DSP horsepower 
  required, the box only needed an ISDN chipset.

What does the DSP have to do with ISDN?  Is it used to produce digitized
voice that could then be heard by someone with voice bearer service?  Or is
it just a convenient way to get 128 kbps out of the box?
Newsgroups: comp.dcom.isdn
From: steveh@rtsg.mot.com (Steve M. Hoffman)
Subject: Re: ISDN support for NeXT computers
Keywords: ISDN, NeXT, Hayes ISDN eXTender, 3.0
Organization: Motorola Inc., International Cellular Subscriber Group, GSM
Date: Fri, 24 Jul 1992 15:41:47 GMT

In article <5a214421.1bc5b@pisa.citi.umich.edu> Jim.Rees@umich.edu writes:
>What does the DSP have to do with ISDN?  Is it used to produce digitized
>voice that could then be heard by someone with voice bearer service?  Or is
>it just a convenient way to get 128 kbps out of the box?

Like I said, I'm no ISDN expert.  I can only assume that the DSP
provides higher speeds in and out of the machine than you can get 
from a dumpy old serial port.  As for the details of what else
you can do with the DSP and ISDN (if there is any corelation at
all) is to wait for the ISDNKit docs to become available.  I
wouldn't want to give out incorrect information.  Try asking at
comp.sys.next.misc.
-- 
Steve Hoffman <steveh@rtsg.mot.com>
Motorola Inc. Arlington Heights, IL
All opinions are my own.
Big corporations have none.
Newsgroups: comp.dcom.isdn
From: nbhandar@enuxha.eas.asu.edu (Narendra Bhandari )
Subject: Request for FAQs
Organization: Arizona State University, Tempe, AZ
Date: Wed, 22 Jul 1992 01:50:05 GMT

Hi I am relatively new to this Newsgroup.

I was wondering if some body could mail me any FAQs appearing 
in this newsgroup.

Thanx.

--
|-^-^-^-^-^-------------Narendra Bhandari-------------------^-^-^-^-^	|
o  Internet nbhandar@enuxha.eas.asu.edu	   				o
|  950 S Terrace Rd ,#c243 Tempe AZ 85281	(602) 921-3401	    -	|
	GENIUS IS 99% PERSPIRATION , 1% INSPIRATION
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: Caller identification of PSTN caller
Organization: AT&T
Date: Wed, 29 Jul 1992 14:04:24 GMT

>Helge.Oldach@Stollmann.DE (Helge Oldach) writes:
>
>>Mostly, you can't distinguish POTS calls from ISDN calls. The reason
>>is that many switches and most long-distance line bules are already
>>digital, it's only the connection between the telephone and the switch
>>that is analogue. In this case, you cannot distinguish the calls as the
>>switch generates the proper phone number. That's different if non-digital
>>switches are involved, of course.

I would also note a couple of additional things:

1. A large number of switches in the US are "Analog Stored Program Control"
switches - computerized central control driving an analog switch matrix.
The venerable 1A ESS(TM) is the most prevalent of this type; it makes up a
significant portion of the embedded base of local exchanges.  The 1A is
capable of supporting SS7 and CLASS(SM) features, but not ISDN.  Even though
it's a non-digital switch, it provides the terminating switch with the
proper network-determined calling line number as would a digital switch
serving an analog line.

2. In a network supporting the full ANSI T1.607 message set, a terminating
ISDN customer, when called by a non-ISDN customer, will receive in the SETUP
message a Progress Indicator information element indicating "interworking at
the originating end".  However, I don't know if (a) this is supported by
Bellcore TR-268; (b) if so, if TR-268 gives any recommendations on how CPE
should display this to the user; or (c) if any switch and CPE vendors
support this, even if it is in TR-268.  We're talking serious theoretical
here.

Referring to the comments marked '>>', bharrell@garfield.catt.ncsu.edu (Ben Harrell) writes:
>  If CCS7 links do exist between the
>switches (usually through an STP network), then the CLID will always be sent
>to the terminati  If not, it won't.  There is one exception to this. 
>For inter-LATA toll calls, the current FG-D tariffs do not provide for the
>inter-LATA carrier sending the CLID to the terminating telco, even if the
>signaling setup is CCS7.  If anyone who works for AT&T, MCI, or Sprint could
>shed some light on this arrangement and CLID, I would appreciate it.

Not really, except to say "the current FG-D tariffs do not provide for the
inter-LATA carrier sending the CLID to the terminating telco, even if the
signaling setup is CCS7."  Any LEC people out there care to comment?

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!houxa!deej     Switching & ISDN Implementation
From: Helge.Oldach@Stollmann.DE (Helge Oldach)
Newsgroups: comp.dcom.isdn
Subject: Re: The D channel: how is it used & billed?
Date: 21 Jul 92 14:31:30 GMT
Organization: Stollmann GmbH, D-2000 Hamburg 50, Germany
Originator: he@sup

dank@blacks.jpl.nasa.gov (Dan Kegel) writes:
| Q. D channel uses x.25, I hear.  Does this mean that multiple D channel
|    conversations can be going on simultaneously?

It uses layer 2 of X.25 in a slightly modified form, called LAP-D,
defined in Q.921/I.441. In fact, only one of the HDLC addresses is used
for the layer 3 ISDN protocol traffic.

Being more precise: SAPI 0 is for signalling, SAPI 1 for packet mode
communications with Q.931 signalling, SAPI 16 for packet data conforming
to X.25 layer 3, 63 for layer2 management. Others are unassigned yet,
but reserved for future standardisation.

X.31 (covering X.25 over ISDN generally) defines integration of X.25
over the D channel.

To my knowledge there is no European carrier that allows usage of
other layer 2 addresses than the layer 3 protocol one. Don't know what
it's like in the US.

| Q. Is there any scheme being used by PPP or terminal adaptor vendors to
|    automatically switch over from D channel to a B channel when traffic
|    gets heavy enough to warrent the extra cost?

Won't be hard to implement, eh? However, this is not covered by X.31.
One would probably shut down the D channel packet link and establish
a new packet link over the B channel. These are separate connections.
-- 
Helge.Oldach@Stollmann.DE
From: Helge.Oldach@Stollmann.DE (Helge Oldach)
Newsgroups: comp.dcom.isdn
Subject: Re: Caller identification of PSTN caller
Date: 28 Jul 92 09:09:39 GMT
Organization: Stollmann GmbH, D-2000 Hamburg 50, Germany
Originator: he@sup

ocl@cc.imperial.ac.UK (Olivier M.J. Crepin-Leblond) writes:
| I would like to know if Narrow-band ISDN (2B + D) can identify callers
| from non-isdn networks; for example a caller from the PSTN using POTS
| calling an ISDN number. 

Mostly, you can't distinguish POTS calls from ISDN calls. The reason
is that many switches and most long-distance line bundles are already
digital, it's only the connection between the telephone and the switch
that is analogue. In this case, you cannot distinguish the calls as the
switch generates the proper phone number. That's different if non-digital
switches are involved, of course.
-- 
Helge.Oldach@Stollmann.DE
Newsgroups: comp.dcom.isdn
From: dror@digibd.com (Dror Kessler)
Subject: Re: IP Router for BRI?
Organization: DigiBoard Incorporated, Eden Prairie, MN
Date: Thu, 23 Jul 1992 15:45:16 GMT

In article <GLARSON.92Jul20095920@bmerh969.bnr.ca> glarson@bmerh969.bnr.ca (Greg Larson) writes:
>I would like to see an X-server running on a PC/Mac over an
>ISDN B-channel. A modem just doesn't cut it, but 56K clear
>might be enough for good performance (then I might be able
>to cost-justify ISDN to my home!!).
>

From out experience:

1. X terminals over a 56/64 Kbps (like the one I'm using now) are quite
   usable. 

2. a 2 B channel connection is even better.

3. As long as everybody else is pluging their products, DigiBoard makes 
   the product just for your case: 

	IMAC, an ISDN MAC-Layer Bridge, for personal or network use.
	1 or 2 B channels, 
	Calls over data or voice lines,
	TCP/IP network managment.
	[ and a long list of other features ...]

 	For more info & $$$, e-mail me

	(if this plug offends any one, flame)


-----------------------------------------------------------------------------
Dror Kessler                                         phone: (612)943-5374
Senior Memeber of Technical Staff                    fax:   (612)943-0803
DigiBoard
6400 Flying Cloud Drive
Eden Prairie, MN 55344                               e-mail: dror@digibd.com
-----------------------------------------------------------------------------
From: ckd@eff.org (Christopher Davis)
Newsgroups: comp.dcom.isdn
Subject: Re: Network Connections over ISDN
Date: 31 Jul 92 17:33:28 GMT
Distribution: usa
Organization: Electronic Frontier Foundation Tech Central

JN> == Virtual Me <jonathan@mentor.cc.purdue.edu> 

 JN> I was wondering how transparent this will be, for example, once
 JN> things are configured, would someone be able to ftp, rlogin, etc.
 JN> on my machine without really even being aware of the ISDN link?  It
 JN> seems to be to good to be true, that something like that could even
 JN> be possible.

There are college campuses that only have 56kbps connections to the
Internet.  Using a B channel, you could have 56kbps or 64kbps to your
home (or more, if you use two B channels).

I've done X over a 56kbps line.  It wasn't too bad, and I was sharing
the line with quite a bit of other traffic (mail, ftp, etc).  Certainly
an *unshared* 56kbps line would be plenty for a single machine...
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
   ``The First Amendment is often inconvenient.  But that is besides the
  point.  Inconvenience does not absolve the government of its obligation
         to tolerate speech.'' --Justice Anthony Kennedy, in 91-155
From: martin.baines@uk.sun.com (Martin Baines - Sun UK - SE Manager Cambridge)
Newsgroups: comp.dcom.isdn
Subject: Re: Network Connections over ISDN
Date: 31 Jul 92 14:56:52 GMT
Reply-To: martin.baines@uk.sun.com
Organization: Sun Microsystems Ltd
NNTP-Posting-Host: bottomdog.uk.sun.com

In article 55650@mentor.cc.purdue.edu, jonathan@mentor.cc.purdue.edu (Virtual Me) writes:
>I just read this group for the first time tonight (morning actually :-)
>since a friend and I were discussing the possibility of hooking our personal
>systems into the net someday via ISDN (which I don't believe exists in any
>form here in town outside the Purdue campus).  From the messages I read, it
>does seem that doing things like running Xwindows over ISDN is very viable.
>
>I was wondering how transparent this will be, for example, once things are
>configured, would someone be able to ftp, rlogin, etc. on my machine without
>really even being aware of the ISDN link?  It seems to be to good to be
>true, that something like that could even be possible.

It depends how you use ISDN. For instance, if you use ISDN to route
IP packets over the D channels, then (subject to getting the software
right :-)) it should work exactly as you describe. The technology
to do this all (more or less) exists: what that needed is something
to encapsulate IP packets (say PPP), a piece of software to
handle call set up and pull down, and an agreed scheme for mapping
IP addresses to ISDN addresses.

Your dream may not be too far from being realised!

---
----------------------------------------------------------------------------
"You might say that, but I couldn't possibly comment"

Martin Baines, Sales Support Manager,
Sun Microsystems Ltd, 306 Science Park, Cambridge, CB4 4WG, UK
Phone: +44 223 420421                 Fax: +44 223 420257
JANET:     Martin.Baines@uk.co.sun    Other UK:  Martin.Baines@sun.co.uk
Internet:  Martin.Baines@UK.sun.com
X.400:     g=martin s=baines prmd=sunir admd=mci c=us
Newsgroups: comp.dcom.isdn
From: bharrell@garfield.catt.ncsu.edu (Ben Harrell)
Subject: Re: Caller identification of PSTN caller
Organization: North Carolina State University
Date: Tue, 28 Jul 1992 12:03:01 GMT

Helge.Oldach@Stollmann.DE (Helge Oldach) writes:

>Mostly, you can't distinguish POTS calls from ISDN calls. The reason
>is that many switches and most long-distance line bules are already
>digital, it's only the connection between the telephone and the switch
>that is analogue. In this case, you cannot distinguish the calls as the
>switch generates the proper phone number. That's different if non-digital
>switches are involved, of course.

At least in the USA this is not necessarily true.  In order for calling line
id (CLID) to transmitted from switch to switch, CCS7 links have to exist
between the switches, whether its a local, intra-LATA toll, or inter-LATA
toll.  Without CCS7, this CLID will not be transmitted, regardless as to
whether the call is POTS, CLASS, or ISDN.  If CCS7 links do exist between the
switches (usually through an STP network), then the CLID will always be sent
to the terminati  If not, it won't.  There is one exception to this.
For inter-LATA toll calls, the current FG-D tariffs do not provide for the
inter-LATA carrier sending the CLID to the terminating telco, even if the
signaling setup is CCS7.  If anyone who works for AT&T, MCI, or Sprint could
shed some light on this arrangement and CLID, I would appreciate it.


Ben Harrell, Staff Manager     | bharrell@catt.ncsu.edu
Costing and Tariffing Support  | Voice:  (919) 992-7647
Public Networks Marketing      | Fax:    (919) 992-3835
Northern Telecom Inc.          | My opinions are my own and do
Research Triangle Park, NC, USA| not represent the views of NTI


Newsgroups: comp.dcom.isdn
From: acjohn@lims01.lerc.nasa.gov (SANDRA JOHNSON)
Subject: ISDN on a Sun Workstation
News-Software: VAX/VMS VNEWS 1.41    
Organization: NASA Lewis Research Center
Date: 28 Jul 1992 09:01 EST  

I have never posted to this newsgroup before, but have been reading your 
postings a lot, and thought this might be a good place to get some answers.

I am currently trying to design a system to use PRI ISDN on a Sun 
Workstation.  For some background, I'm working for NASA on the Advanced 
Communication Technology Satellite (ACTS).  Our ground station has ISDN PRI 
capabilities, and I'm trying to demonstrate these capabilities at our 
demonstration area which will be here at NASA Lewis Research Center.  We 
have purchased a Sun IPX workstation to do other demonstration things, and 
my job is to use that Sun to demonstrate ISDN.  I am new to ISDN and new to 
Sun, so am having a lot of fun!  

I have contacted Sun to try to get ideas on how to do this best, and seem 
to be stuck at how to get an ISDN card.  They gave me the names and numbers 
of foreign ISDN BRI card makers, but I would really like to use a US 
manufacturer if possible.  I also have had no luck finding a PRI ISDN card, 
which is what I really want.  Does anyone have any ideas?

I am planning on doing a "multimedia" type of system.  I think I will be 
using a software package from a company called Insoft.  The package is 
called "Communique!".  This also allows for video - I've talked to Parallax 
about their XVideo card and that looks pretty good.  Any suggestions would 
be greatly appreciated!

Newsgroups: comp.dcom.isdn
From: nagle@netcom.com (John Nagle)
Subject: Re: The D channel: how is it used & billed?
Date: Fri, 24 Jul 92 07:09:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

bharrell@garfield.catt.ncsu.edu (Ben Harrell) writes:
>Call setup times for B-channel is typically 15-20
>secs before data can be transmitted, whereas X.25 is typically 3-6.

      15-20 seconds for call setup?  All this digital computer-controlled
switch technology and we have call setup times that would be high for
a #5 crossbar.  If that's ISDN, I want to go back to electromechanical
switching.

      Thought for today: if the original '60s Picturephone had been implemented,
using 1MHz analog signals switched through a modified #5 crossbar, we'd
have a great infrastructure for data.  Modern modem technology could
squeeze near-Ethernet rates through a Picturephone channel.  Would
have been good.

					John Nagle
Newsgroups: comp.dcom.isdn
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: The D channel: how is it used & billed?
Organization: Digital Equipment Corp., Littleton MA USA
Date: Wed, 22 Jul 1992 20:48:11 GMT


In article <dank.711395231@blacks.jpl.nasa.gov>, dank@blacks.jpl.nasa.gov (Dan Kegel) writes...
>I am interested in linking several developer's home PC's into a LAN at
>the office of the company they work for.  Currently, I plan to use
>an ethernet-bridging PPP (RLN from ICC) and V.32bis modems.
>It would be nice to have the higher speed and lower setup time
>that ISDN offers.  Now, the high-speed B channels are great at moving
>lots of data, but expensive, and can only connect to one station at a time.
>It would be very nice if I could use the low-speed D channel when traffic 
>is light to save money, or to stay in touch with more than one station at the 
>same time. Properly motivated, here are my novice's questions:

>Q. How is D channel traffic billed?  Is it per-byte or per minute?

In the Massachusetts tariff, which applies to residence and business
customers, packet traffic is charged on a usage basis.  While there
is a trivial (2 cents, I think) charge for call setup, there is no
connection time element.  Packets are charged at 60 cents per 
kilosegment (the usual X.25 segment:  Small packets are segments,
large packets are a segment per -- I think -- 128 bytes or fraction
thereof) during busy hour, and 50 cents during off hours.  This is
just intra-LATA; there aren't inter-LATA links yet, but they'd no
doubt incur multiple carriers' charges.

>Q. Is there any scheme being used by PPP or terminal adaptor vendors to
>   automatically switch over from D channel to a B channel when traffic
>   gets heavy enough to warrent the extra cost?

I've not seen any vendors build that in to their equipment yet.
It would certainly be a nice feature to build into, say, one's 
IP-over-ISDN driver.  

BTW, none of the three commercially-available (in the US) ISDN
to Ethernet bridges use the D channel.  It's really too slow for
general-purpose bridging.  But it's fast enough for some remote
terminal apps., background transfers, mail, etc.
---
Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.
Newsgroups: comp.dcom.isdn
From: scott@labtam.labtam.oz.au (Scott Colwell)
Subject: Re: The D channel: how is it used & billed?
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Thu, 23 Jul 1992 23:56:56 GMT

etxorst@eos.ericsson.se (Torsten Lif) writes:
>Some reasons to use the D-channel anyway could be:
>    The data rate is VERY low but you still want it transmitted in
>    fairly small packages and presumably over a long time. Since
>    there's no time charge to a D-channel connection, you can keep it
>    open as long as you want and only pay for the actual data. With a
>    B-channel connection you'd need to accumulate data over a longer
>    time to build up a package sufficiently large to merit a full
>    setup-transmit-disconnect cycle. (I had to strain myself to come up
>    with this one. I doubt if there is any real traffic situation that
>    fits the bill.)

This is in fact one of the big future uses for isdn.  People want it
for telemetry.

e.g.	* monitoring security systems (many $$$s in savings here!)
	* remote meter reading.  (read the electricity/gas/water meter
	  from the central office.)
	* remote control of house. (turn on heater before leaving work,
	  program the video to record something.)

My last example is rather contrived but the first two are real and under
development.
-- 
Scott Colwell				Labtam Australia Pty. Ltd.
net:	scott@labtam.labtam.oz.au	41 Malcolm Rd., Braeside
phone:	+61-3-587-1444			Melbourne, Australia  3195
From: spero@hpindda.cup.hp.com (Spero Koulouras)
Date: Wed, 22 Jul 1992 19:07:39 GMT
Subject: Re: IP Router for BRI?
Organization: HP Information Networks, Cupertino, CA
Newsgroups: comp.dcom.isdn

Hewlett-Packard also sells an ISDN router.  Our product supports
full TCP/IP to ISDN BRI routing with dynamic allocation of 1 to 6 B channels.
It is deisgned to work with our PC and workstation ISDN products and
will support the home-office concept mentioned by the original poster.
The products are:

  ISDN Server           $18375
  ISDN Link/MS DOS        2590
  ISDN Link/Unix          2750

These are U.S. list prices.  The June 22 issue of ComputerWorld has 
a writeup on these products.  

For more information please contact your local HP sales office.  If they
are unable to provide the information you need,  please e-mail me
directly as my reading of this group is infrequent.

Regards,

  Spero Koulouras
  e-mail:  spero@cup.hp.com
Newsgroups: comp.dcom.isdn