HDTenEightyP/NetNews huggingface dataset:
From: ocl@cc.imperial.ac.UK (Olivier M.J. Crepin-Leblond)
Subject: Caller identification of PSTN caller
Organization: The Ohio State University Department of Computer and Information Science
Date: Sat, 25 Jul 1992 17:54:07 GMT

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. 
Thanks for your help,

-- 
Olivier M.J. Crepin-Leblond, Comms & Sig.Proc, Elec. Eng. Department
 Imperial College of Science, Technology and Medicine, London, UK.
   Internet/Bitnet: <ocl@cc.ic.ac.uk> - Janet: <ocl@uk.ac.ic.cc>

Newsgroups: comp.dcom.isdn
From: rees@dabo.citi.umich.edu (Jim Rees)
Subject: Re: Frame Relay / X.25 ?
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Thu, 23 Jul 1992 14:02:20 GMT

In article <dank.711677134@blacks.jpl.nasa.gov>, dank@blacks.jpl.nasa.gov (Dan Kegel) writes:

  So what's the real story?  Is TCP/IP over PPP over FR over ISDN the wave of
  the distant future for dialup IP?

I think the two choices are tcp/ip/ppp/isdn vs. tcp/ip/fr/isdn.  It wouldn't
make much sense to mix fr and ppp.

Right now, most ip traffic over isdn is carried by ppp.  This is natural,
since the B-channel can be treated as just a high speed modem.  There are
even companies that make terminal adapters that look just like a Hayes
modem.

In the future, it might make more sense to carry ip over frame relay.  It
all depends on whether you want the phone network to be part of your packet
switch.  Right now the phone companies don't really offer any packet
services (x.25 doesn't count), but in the future they might.  Some people
claim that they don't want the phone company involved in switching their
packets, for a variety of reasons, most of them regulatory.

Other reasons to prefer frame relay might include the simplicity of the
protocol (no state machine required) and the availability of existing
hardware (Telios, etc).  Some of us are already using frame relay framing
without the frame relay service.

The actual frame relay framing is simple, and is described in rfc 1294 and
ansi t1.618.  It has forward and backward congestion notification but no
flow control and no reliable delivery.  This is pretty much exactly what you
want for tcp/ip, miraculously enough.
Newsgroups: comp.dcom.isdn
From: sproule@phoenix.Princeton.EDU (William J.  Jr. Sproule)
Subject: Re: IP Router for BRI?
Followup-To: comp.dcom.isdn
Originator: news@ernie.Princeton.EDU
Keywords: Combinet Digiboard BRI
Organization: Princeton University
Date: Tue, 21 Jul 1992 13:46:18 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!!).
|> 
|> -G.Larson
|> --
|> ----------------
|> Greg Larson  (glarson@bnr.ca)              Bell-Northern Research, Ltd.
|> GSF/ISDN Software Design                   Ottawa Ontario Canada
|> Opinions expressed are not necessarily those of BNR.


We are doing that today.  We have been using Combinet and Digiboard 
Ethernet bridges.  I have a Macintosh connected to a Shiva Fastpath
at home.  With both B channels up, it is slightly slower then
LocalTalk, but not noticably so.  Only one channel is fine for
xterms, xlock, ups.  For xmh and xrn, you really need 2B.  

-b

-- 
William J. Sproule - Networking  	Princeton University
UUCP:     	...princeton!sproule	87 Prospect Ave.
INTERNET:	sproule@Princeton.EDU	Princeton, NJ   08544
BITNET:		SPROULE@PUCC		VOICE: 609-258-6089  FAX: 609-258-3943
From: welch@xcf.Berkeley.EDU (Sean N. Welch)
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN support for NeXT computers
Date: 21 Jul 1992 19:02:24 GMT
Organization: Experimental Computing Facility, U.C. Berkeley
NNTP-Posting-Host: xcf.berkeley.edu
Summary: NeXT ISDN stuff in the FAQ - sure
Keywords: ISDN, NeXT, Hayes ISDN eXTender, 3.0

In article <1992Jul21.140217.17351@rtsg.mot.com> steveh@rtsg.mot.com 
(Steve M. Hoffman) writes:
[ bits deleted ]
> I figure that if that Sparc 10 got into
> the FAQ, the NeXT should be there too...  
[ more bits deleted ]

You are absolutely right.  I'm collecting some more information, but 
NeXT will be featured in the next posting of the FAQ.  I remember a 
press release from Hayes, but I haven't been able to dig it up.  If
anyone has a pointer to a copy, I'd appreciate it.  In fact, if you 
have any information about vendors supplying ISDN equipment that isn't
mentioned in the FAQ, please let me know.


Sean N. Welch                       \\/                 welch@xcf.Berkeley.EDU
Experimental Computing Facility     /\\     University of California, Berkeley
Newsgroups: comp.dcom.isdn
From: rees@pisa.citi.umich.edu (Jim Rees)
Subject: Re: Frame Relay / X.25 ?
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Fri, 24 Jul 1992 21:18:17 GMT

In article <dank.711937465@blacks.jpl.nasa.gov>, dank@blacks.jpl.nasa.gov (Dan Kegel) writes:

  I'm very interested in being able to have multiple virtual circuits on a 
  single B channel; it makes a lot of sense for, say, a BBS, because 
  instead of running out of lines when there are many users, one gets graceful 
  degradation; they have to start sharing the bandwidth.

I predict that frame relay won't become viable in the US for a long time.
The problem is that the phone companies will get greedy and want more money
for this service than it would cost you to do it yourself.  I also predict
that someone (not the phone company) will wise up and offer "frame relay
bypass," in spite of the phone company raising technological barriers in
order to promote their own over-priced services.  Ah, politics.

  Don't you suffer from the lack of compression that PPP would provide?

Compression is a completely separate issue from data link, and has nothing
whatever to do with ppp.  If someone tries to tell you different, check
their commercial affiliation.  Some of us would even claim that compression
is a transport layer issue, since by definition it's context sensitive.
From: wilson@sundance.llnl.gov (Michael Wilson - USC )
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN on a Sun Workstation
Date: 30 Jul 92 00:28:34 GMT
Organization: Magnetic Fusion Energy - LLNL

acjohn@lims01.lerc.nasa.gov (SANDRA JOHNSON) writes:


>I am currently trying to design a system to use PRI ISDN on a Sun 
>Workstation. 

>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?

If you really want to save yourself pain, upgrade the IPX to a SparcStation 10
model 30 or 41.  They come with an isdn port.  Depending on your discount level
(probably 40%) your cost would be (approx) $5,700 or $9,400. 

>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!

-mike
Newsgroups: comp.dcom.isdn
From: varney@cbnewsd.cb.att.com (Al Varney)
Subject: Re: Caller identification of PSTN caller
Organization: AT&T Network Systems, Lisle, IL
Distribution: na
Date: Tue, 28 Jul 1992 21:15:22 GMT

Helge.Oldach@Stollmann.DE (Helge Oldach) writes:
>Mostly, you can't distinguish POTS calls from ISDN calls...
>That's different if non-digital switches are involved, of course.

   I'm confused -- what does the switch type have to do with the
transmission of CLID??  AT&T 1A ESS(tm) switches are NOT digital,
but were the first to support CLID.


In article <bharrell.712324981@garfield.catt.ncsu.edu> bharrell@garfield.catt.ncsu.edu (Ben Harrell) writes:
>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 [.... transmission error ? ]

   If you meant that "CLID will always be sent to the terminating
Switch", I would agree.  Whether it is delivered to the Called
Party depends on switch features/options and the physical equipment
at the end of the line.  ISDN can receive CLID, but doesn't get
it automatically, any more than an analog line will get CLID.

   General statement....  The type of telephone has little to do
with CLID.  The signaling path between the telephones is the key.
Along with CCS7 (aka SS7), other signaling supporting CLID are:
CCIS6 and ISDN PRI (to PBXs or between Switches).  Note that the
use of ANI is NOT implied here -- ANI is not CLID, in either the
transmission, meaning or content.

> ... 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.

   Well, I work for AT&T (the vendor), not AT&T (the network), but
I do have a copy of some material Bell Atlantic passed out at a
Forum discussing SS7 interconnection from their perspective.  They
indicated that their tariff filing allowed for the transmission of
Calling Party Number (that's the CLID info. in SS7) to IXCs as a
no-charge option.  They expected IXCs receiving this information
to also deliver it to Bell Atlantic on terminating calls.  Charge
Number and the OLI parameter (equivalent to ANI) are also optional.

   While Bell Atlantic's position may have changed, I would bet
the tariff is already in place.  Whether you call the tariff a
FG-D tariff using SS7, or an SS7 TR-394 tariff is a problem,
in that the current TRs for "FG-D" explicitly require MF.  So
one could say that FG-D tariffs don't support CLID ... but that's
because FG-D isn't SS7.

Al Varney - just MY opinion.
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Newsgroups: comp.dcom.isdn
Subject: Re: The D channel: how is it used & billed?
Date: 23 Jul 92 23:19:10 GMT
Organization: Digital Equipment Corp., Littleton MA USA


Vernon Schryver writes, 
>So a long distance B channel is about 17 times as cheap as a D-channel.
>A v.32bis modem is about 8 times as cheap as a D-channel.

Only on a per-bit basis.  Many applications are time-based.  Reading
videotex, mail, etc., on line are "session" applications, where the
time you spend on line is important, and you're not streaming data
most of the time (i.e., when reading a screen).  On a per-hour basis,
the D channel connection, with such text-mode usage, may be cheaper
than B channel connections, especially if it's a toll call (on the 
B channel; packet generally has no local/toll distinction).

After all, it's just plain old X.25, and Telenet has been doing it
that way for years and years.
---
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.
From: dem@nhmpw2 (David E. Martin)
Newsgroups: comp.dcom.isdn
Subject: Need ISDN Phone Sets
Date: 28 Jul 92 19:09:11 GMT
Reply-To: dem@fnal.fnal.gov
Organization: Fermi National Accelerator Laboratory,  Batavia, IL,  USA

I need to get about 6 ISDN phone sets for use in an experiment I am
setting up.  They should work with the 5ESS and have a LCD screen for
internal Caller-ID.  AT&T wants about $600 for their sets, which is
out of mu budget range.  Does anyone have a suggestion for some more
reasonably prices sets?


David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-2783
P.O. Box 500, MS 234; Batavia, IL 60510  USA   /  \   E-Mail: DEM@FNAL.FNAL.Gov
Newsgroups: comp.dcom.isdn
From: bharrell@garfield.catt.ncsu.edu (Ben Harrell)
Subject: Re: The D channel: how is it used & billed?
Organization: North Carolina State University
Date: Thu, 23 Jul 1992 11:36:36 GMT

The best and most obvious use of the D-channel and X.25 data is for short
bursty transmissions of data, such as ATMs, POS transactions, credit card and
check validations, etc.  Call setup times for B-channel is typically 15-20
secs before data can be transmitted, whereas X.25 is typically 3-6.


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: bharrell@garfield.catt.ncsu.edu (Ben Harrell)
Subject: Re: The D channel: how is it used & billed?
Organization: North Carolina State University
Date: Fri, 24 Jul 1992 13:57:24 GMT

nagle@netcom.com (John Nagle) writes:

>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


Hi John, nice to here from you.  Yes I agree with you on the 15-20 sec 
setup times being very long, and they are instantaneous with digital switch-
ing and local interoffice SS7.  I was referring to long distance (LATA-to-
LATA), which with all of the mixtures of DP, MF, SS7, FG-B, and FG-D, can
easily reach this range.  The recent FCC decision of 800 number portability
and its effect of greatly accelerating the deployment of SS7 on an intra-
LATA basis will reduce this to below 10 secs, but its not going to drop
much below this until AT&T, MCI, and Sprint are all connected to the intra-
LATA telco's networks using SS7, instead of MF or DP.  The is proceeding 
very slowly.  The FCC decision only addresses the call setup times for the
telco to present an originating call _to_ the inter-LATA carrier.  This 
setup must be reduced to an average of 2.5 secs for 100% of originating
_800_ calls, with a maximum of no more than 5 secs on any given call, by
1995.

What a great idea about the original picturephone!  <sigh...>


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: lap@sol.asl.hitachi.com (Larry Pearlstein)
Subject: TCP/IP over ISDN - Macs, PC's, and Suns
Keywords: TCP,IP,Macintosh,PC,Sun
Reply-To: lap@sol.asl.hitachi.com
Organization: Hitachi America Ltd
Distribution: usa
Date: Wed, 29 Jul 1992 16:05:14 GMT

I'm interested in using ISDN to connect to our office
TCP/IP (Ethernet) network from home, via Macintoshes
and PCs.  The main applications would be X-Windows,
mail, FTP and Telnet.  Can anyone provide info on the
hardware and software needed for the Sparcstation 2,
Macs, and PCs to accomplish dialup B channel IP?

I imagine needing an S-bus BRI card with some kind of
dialup IP over B channel software support for the Sun.
For the Mac, a BRI NuBus board with dialup IP over BRI
integrated into MacTCP.  For the PC, BRI AT-bus board -
is there any portable way to link applications to TCP/IP?

I'd like to know who makes the hardware and software and,
especially, is this going to be useful, or a grand pain
in the neck to get working?

Thanks for any info.

			Larry Pearlstein
			lap@sol.asl.hitachi.com

Newsgroups: comp.dcom.isdn
From: dank@blacks.jpl.nasa.gov (Dan Kegel)
Subject: Re: Frame Relay / X.25 ?
Organization: Image Analysis Systems Group, JPL
Date: Fri, 24 Jul 1992 00:24:25 GMT

rees@dabo.citi.umich.edu (Jim Rees) writes:
>In the future, it might make more sense to carry ip over frame relay.  It
>all depends on whether you want the phone network to be part of your packet
>switch.  Right now the phone companies don't really offer any packet
>services (x.25 doesn't count), but in the future they might.  Some people
>claim that they don't want the phone company involved in switching their
>packets, for a variety of reasons, most of them regulatory.

I'm very interested in being able to have multiple virtual circuits on a 
single B channel; it makes a lot of sense for, say, a BBS, because 
instead of running out of lines when there are many users, one gets graceful 
degradation; they have to start sharing the bandwidth.

>Other reasons to prefer frame relay might include the simplicity of the
>protocol (no state machine required) and the availability of existing
>hardware (Telios, etc).  Some of us are already using frame relay framing
>without the frame relay service.
>The actual frame relay framing is simple, and is described in rfc 1294 and
>ansi t1.618.  It has forward and backward congestion notification but no
>flow control and no reliable delivery.  This is pretty much exactly what you
>want for tcp/ip, miraculously enough.

Don't you suffer from the lack of compression that PPP would provide?
- Dan Kegel (dank@blacks.jpl.nasa.gov)
Newsgroups: comp.dcom.isdn
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: The D channel: how is it used & billed?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Jul 1992 02:23:16 GMT

In article <1992Jul22.195218.9871@nntpd.lkg.dec.com>, goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
> ...
> >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. ...


Do I understand this right? $0.60/(1000*128Bytes)  Or $8*.6 = $4.80/MByte?


A v.32bis modem will move about 1400*3600 Bytes/hr or 5MB/hr of
uncompressible (e.g. pre-compressed) data, and perhaps 20MB/hr of ASCII
text.

A single B-channel running at 56Kbit/sec (instead of 64K because of the
inter-CO problems) will move about 25MByte/hour with no compression.

I've been told you can get switched-56 to connect your B channels at
the same rates as long distance.  Long distance costs about
$0.11/minute anywhere in the U.S. if you're willing to pay a front-end
fee of about $10/month.  (Or so Sprint, MCI, and AT&T all tell me for
my personal bills, which involve some significant to me long distance
charges for PEP and v.32bis.)

Thus, for $4.80 you should be able to move about 17.6MBytes through a
B-channel to anywhere in the U.S., after you get the call set up, and the
computers logged-in or whatever.

You can move only about 8.7MByte for $4.80 with a v.32bis/v.42/v.42bis
modem.

So a long distance B channel is about 17 times as cheap as a D-channel.
A v.32bis modem is about 8 times as cheap as a D-channel.


What have I computed wrong?  Why is anyone even slightly interested in
buying D-channel bits?


Vernon Schryver,  vjs@sgi.com
From: jonathan@mentor.cc.purdue.edu (Virtual Me)
Newsgroups: comp.dcom.isdn
Subject: Network Connections over ISDN
Date: 31 Jul 92 08:34:41 GMT
Distribution: usa
Organization: Purdue University

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.


Thanks for satisfying my curiousity,

Jonathan


___ |Jonathan      |Internet:jonathan@mentor.cc.purdue.edu|Whom computers
|__||Neuenschwander|NeXTmail:buzz@symphony.cc.purdue.edu  |would destroy, they
|   |              |America Online:Buzz Lee               |must first drive mad
From: magu@se.alcbel.be (Mike Aguilar)
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN support for NeXT computers
Keywords: ISDN, NeXT, Hayes ISDN eXTender, 3.0
Date: 22 Jul 92 06:57:01 GMT
Reply-To: magu@se.alcbel.be
Organization: Alcatel Bell Antwerp (AAL)


--

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

>In all the discussion on ISDN in Solaris 2.x and Sparc 10 machines
>there's been no mention of the ISDNKit in NeXTSTEP 3.0 due August
>'92 (now in 2nd beta release).  By using an ISDN eXTender box, available
>from Hayes, you can use the NeXT DSP external port as a high speed
                            ^^^^^^^^^^^^^^^^^^^^^^
>ISDN connection....<etc deleted>


Could you tell us more about this DSP port (eg. what's it like compared to
ordinary comm ports, are they easier to program, how fast etc...) Sorry
but I don't have a copy of the NeXTWORLD Summer '92 edition. 


--
  // Mike Aguilar                          Phone: (32) 3 240 4289
\//  email : magu@se.alcbel.be             BELL ext. 4289
From: berger@sfc.sony.com (Bob Berger)
Newsgroups: comp.dcom.isdn
Subject: Mobile ISDN?
Keywords: n
Date: 24 Jul 92 18:23:58 GMT
Organization: SONY Advanced Video Technology Center San Jose, CA USA

Is there any available support / products that would allow one to be mobile
and still connect to ISDN with at least the same bandwidth that will be
available in primary service (~128kb/sec)?

Is there "celular ISDN", direct satalite ISDN?

-- 
Bob Berger  -  SONY Advanced Video Technology Center
685 River Oaks Parkway  San Jose, CA 95134 408-944-4964 FAX:  408-954-1027  
INTERNET: berger@sfc.sony.com   UUCP: [uunet,mips]!sonyusa!sfcsun!berger