HDTenEightyP/NetNews huggingface dataset:
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
Subject: Re: The ISDN network
Organization: We're from the Government, and we're here to Help you!
Date: Wed, 30 Dec 1992 00:09:14 GMT
	<bob1.725120836@cos> <BzvnE9.Fsw@NeoSoft.com>

In article <BzvnE9.Fsw@NeoSoft.com> jpsb@NeoSoft.com (Jim Shirreffs) writes:
   >Exactly, and if the public would stop chucking bricks and make their
   >needs known to the regulators, we might get somewhere. Some of the
We're from the government, and we're here to help you........  not!

   I have been trying to find out what equipment I need so that I can 
   have an Xwindows session between my home system and my office system.
   ISDN seems to be the best answer. But I cann't get anywhere with my
   local carrier (GTE Houston) also I cann't get anywhere with my OS
   supplier Consensys. So I am going to use SLIP. I think it is a shame

Xproto is a heavy consumer of network bandwidth; all of us NeWS folks
know that NeWS is _better_, though it didn't win in the marketplace :-)
Xproto over vanilla-SLIP over modems will be a dog for most work.
Xproto over CSLIP over modems will be a lot less bad.
But, if your X terminals can support it, you'll do a lot better with
one of the X-over-slow-line protocols like NCD's Xremote,
which package the data sent over the line differently so you can get
decent performance over typical async bandwidths, without TCP overhead.
If your host machine doesn't have drivers for it, some terminal servers 
(I think Xylogics' newer ones?) will convert between Xremote and
vanilla xproto at the terminal server, so your Ethernet-connected host
doesn't have to know you're cheating.

As far as getting your telco to sell you ISDN, keep talking to
supervisors until you find someone who actually knows about ISDN plans.
--
#				Pray for peace;      Bill
# Bill Stewart 1-908-949-0705 wcs@anchor.att.com AT&T Bell Labs 4M312 Holmdel NJ
# !egassem terces eht dnuof ev'uoY  !snoitalutargnoC
From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
Newsgroups: comp.dcom.isdn
Subject: Re: Terminal Adapters
Date: 29 Dec 92 19:06:18 GMT
Reply-To: lstowell@pyrnova.pyramid.com.pyramid.com (Lon Stowell)
Organization: Pyramid Technology Corporation

In article <PICONE.92Dec28142448@csc000.csc.ti.com> picone@csc000.csc.ti.com (Joe Picone) writes:
>I would like to replace some analog modems with "ISDN terminal adapters"
>if possible. Here is my current configuration:
>
>	(57.6K)    (14.4K)			  (14.4K)  (38.4K)
>X terminal -> analog -> analog phone line -> analog -> annex -> ethernet
>	      modem			     modem
>
>(2) The modems operate at v.32 in an UNCOMPRESSED mode.
>
      How slooooooooooooooow.


>Questions:
>
>Can I replace the analog portion (modems/phone lines) with an ISDN
>terminal adapter and ISDN telephone line?
>
    You'd be much better off stepping back and looking at the big
    picture.

    Why not replace the entire kludge with the Combinet ISDN "smart"
    bridges?    

    X-term || Enet <--> Combinet--ISDN======ISDN--Combinet <--> || Host
	   |
    X-term |     

Its really an Ethernet "smart" compression bridge.   

This unit uses an ISDN BRI.  It has dynamic compression/decompression
of data for increased thruput.  It can use a single B channel or
inverse mux both together for 128 Kb thruput.   You can select an 
inactivity timer for the ISDN connection.....if no packets 
are sent, it will disconnect.  As soon as a packet is seen NOT
destined for the local E'net, it reconnects the ISDN circuit.   

Combinet still makes E'net bridges which use leased 56K + circuits,
this new ISDN unit is merely a new flavor of same...except that it
is smart enough to drop the ISDN ckt when it is idle.

   Combinet
   333 W. El Camino Real Suite 310
   Sunnyvale CA 94087
   408-522-9020
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: The ISDN network
Organization: Corporation for Open Systems
Distribution: usa 
Date: Wed, 23 Dec 1992 14:35:12 GMT

In <1992Dec22.222732.16189@atlastele.com> bcapps@atlastele.com (Brent Capps) writes:

>In article <1992Dec22.133824.9230@cbfsb.cb.att.com> deej@cbnewsf.cb.att.com (david.g.lewis) writes:
>>(b) the information content provision of the MFJ was
>>remanded to, and subsequently overturned by, the MFJ court.
>>
>>Of course, if a BOC sees no market for a service, it's not going to face
>>regulatory battles (or even expend regulatory goodwill) to provide it.

>Obviously somebody forgot to tell US West, 'cause according to my ISDN rep
>they've been fighting for some time to get this restriction removed from the
>MFJ.  She said they have been frustrated because marketing data shows there
>is a strong demand for this feature.
>-- 
See previous post - but in effect what we users need to do is inundate
the FCC, Judge Green, and the local PUCs with mail. As President-elect
Clinton has said - education is a priority, and they sure need it.

>Brent Capps                          | 
>bcapps@agora.rain.com (gay stuff)    | Quis corriget correctores ipsos?
>bcapps@atlastele.com (telecom stuff) |

Bob

Newsgroups: comp.dcom.isdn
From: nlane@well.sf.ca.us (Nathan D. Lane)
Subject: 5ESS vs GTD5 in relation to ISDN capability
Organization: Whole Earth 'Lectronic Link
Date: Mon, 21 Dec 1992 07:59:45 GMT

Here at my local phone company, perhaps the worst in the U.S. (GTE), they
have indicated to me that they have 5ESS in two areas of their phone switch
network.  They indicated to me that 5ESS would NOT do ISDN, which I know
to be utter c--p after reading this group.  Unfortunately, I do not connect
with a 5ESS switch - I connect with a GTD5, which I think is Northern
Telecom.  Does anyone know (GTE doesn't) if the GTD5 is capable of ISDN
and can it talk with a 5ESS?  I would like connectivity to the bay area,
which is Pacific Bell, and I know they have a good ISDN offering.  Whereas
Santa Barbara just got DOV (19.2Kbps multiplexed via subcarrier on phone
line) six months ago.  I cannot afford ADN (56Kbps) or the $2000 price
tag on the switched 56K offering (which is supposed to go into MY phone
switch because GTE claims it is not isdn capable).  I really need to do
NFS and X across my line, but at 19.2K, these are pretty unreasonable.
I telecommute 90% of the time to work (even though only 12 miles away,
due to interruptions from users).  I have received responses from those in
my local area (Thanks to Rockwell CMC!) that ISDN is a LONG, LONG ways
off for us.  However, I just wanted to know if the GTD5 is capable of the
ISDN, as well as a stock, base 5ESS (does it need upgrades to do ISDN or
is it a standard capability?)

Thank you for any responses.

-Nathan Lane
Triicon Systems, Santa Barbara, CA
nlane@well.sf.ca.us
From: Arthur@cswamp.apana.org.au (Arthur Marsh)
Newsgroups: comp.dcom.isdn
Distribution: world
Subject: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Date: Thu, 31 Dec 1992 17:55:34 +1000

On Fri 25 Dec at 23:50 Christian Weisgerber wrote: 

 CW> Is V.42bis already defined by the CCITT for use over V.120? 
 CW> I though it was still in the "we're looking into it" 
 CW> stage, which can turn out anything.

The error correcting procedure of V.120 is an allowed error correction
procedure for V.42bis, but until V.42bis is revised, there is no defined method
of negotiating V.42bis parameters in V.120. (The other allowed error correction
protocol for V.42bis, LAPM has an XID defined for exchanging V.42bis
parameters).

So, V.42bis for V.120 is allowed and it's at the "we're looking into it"
stage.

 * Origin: Camelot Swamp MJCNA, Hawthorndene, Sth Australia (8:7000/8)
From: tspencer@pilot.njin.net (Thomas Spencer IV)
Newsgroups: comp.dcom.isdn
Subject: Re: The ISDN network
Date: 2 Jan 93 04:42:25 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


bcapps@atlastele.com (Brent Capps) writes:

>In article <Dec.26.23.48.48.1992.18316@pilot.njin.net> tspencer@pilot.njin.net (Thomas Spencer IV) writes:
>>[speed] is the whole point of ISDN.  What I find so interesting about
>>the people who are saying that ISDN won't catch on is that they are
>>completely ignoring the history of performance in computing.
>>
>>     New, fast equipment is bought because it is faster.
>
>In the PSTN?  Wrong.

       From a customer standpoint, they want the extra speed.  I do, and
unfortunately I don't have a local operating company offering ISDN.
Your opinion of the market, and what drives an open market only highlights
_your_ incorect ideas about the market place.  I will however concur with
your analysis of the phone companies reasons.  We aren't discussing the
internal structure of the PSTN, but the end user terminal.  The long distance
networks of all the major carriers have been installing ISDN type equipment
(Not necessarily ISDN compatible, just all digital systems that use the
64kbps channel to carry voice) since the early '80s.  We should all know that,
and it isn't being questioned.  The whole point is, ISDN will be installed
because customers want the extra capability.  Telecommunications is a 
service and demand oriented industry.  At times, the phone companies need
to create a demand, but on the whole, it is demand oriented. 

Tom.
Newsgroups: comp.dcom.isdn
From: nisimura@sran233.sra.co.jp (Tohru Nishimura)
Subject: Re: Asynchronous TAs
Organization: Software Research Associates, Inc., Japan
Date: Mon, 28 Dec 1992 02:15:50 GMT

vances@xenitec.on.ca (Vance Shipley) wrote;

>>However, the V.110 rate adaption protocol only goes up to 19.2K. This
>>is probably the reason that most TAs only go up to 19.2K.
>
> I don't think this is really true.  I am not an expert but I beleive there
> is no upper end specified.  Can anyone else comment on this?

Kevin wrote true.
As far as my knowledge, V.110 rate adaption protocol goes up to 19.2K.
Just see the adaption scheme.

Here in Japan, you can buy 38.4K async ISDN TA, but the product uses
propriety scheme, which won't connect other TA.

Tohru Nishimura - happy, but frustated home ISDN customer uses
		  19.2K async TA with Xremote.

Software Research Associates, Inc. Tokyo Japan
Newsgroups: comp.dcom.isdn
From: bcapps@atlastele.com (Brent Capps)
Subject: Re: The ISDN network
Organization: Atlas Telecom Inc.
Date: Mon, 28 Dec 1992 17:05:18 GMT

In article <Dec.26.23.48.48.1992.18316@pilot.njin.net> tspencer@pilot.njin.net (Thomas Spencer IV) writes:
>[speed] is the whole point of ISDN.  What I find so interesting about
>the people who are saying that ISDN won't catch on is that they are
>completely ignoring the history of performance in computing.
>
>     New, fast equipment is bought because it is faster.

In the PSTN?  Wrong.  New equipment is brought in because it is cheaper
to operate or corrects deficiencies in the existing network.  Why do
you suppose the BOCs were retiring '50s era crossbar technology and leaving
older '20s era stepper switches?  Because the crossbars were too expensive to 
maintain.  Very few countries in the world invest bucks in their telephone 
infrastructure just for the sizzle of newer, faster technology.  Japan is a 
notable exception, with the government committed to promoting the establishment
of ISDN regardless of whether it's proven to be cost effective.  The jury 
is still out on whether this proactive approach is really more farsighted than
the cost-justified approach being used in most of the rest of the world.

>     I've been involved in retail, and if your gismo doesn't have the
>latest and greatest it won't sell, and if it does, it doesn't matter how
>much you charge, people will buy it.  When people have ISDN available,
>it will be installed mearly because it is faster.  

A retail business is not comparable to a regulated telephone utility.
Market forces operate in different ways.  A retail business strives to
create a demand for a product or service.  A utility, on the other hand,
want to exactly match supply to the predicted demand.  If demand is
stronger than expected, the utility will be unable to react quickly and
frustrated subscribers will complain to the PUC.  If demand is weaker
than expected, the utility's ongoing capital expenses will not be
offset by increased revenue and may force it to apply for a rate increase.  
For these reasons, utilities generally want to *avoid* creating a greater
demand for a service than anticipated.

It is significant to note that ISDN was initially conceived while AT&T
was still a monopoly and owned all the embedded CPE.  The implicit assumption
(for BRI anyway) is that the service will be available end-to-end, a valid 
assumption in those days when everything from end-to-end was under their 
control.  I'm not sure what would have happened had the divestiture never 
occured; the predivestiture phone network is/was littered with occasional 
examples of oddball technologies that were supposed to be the wave of the 
future but never quite caught on, because in the end they couldn't be 
cost-justified.
-- 
Brent Capps                          | 
bcapps@agora.rain.com (gay stuff)    | Quis corriget correctores ipsos?
bcapps@atlastele.com (telecom stuff) |
From: jg@crl.dec.com (Jim Gettys)
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN and DECSTATION/5000
Keywords: Isdn, Decstation, Ultrix, OSF/1
Date: 21 Dec 92 17:31:11 GMT
Organization: Digital Equipment Corporation, Cambridge Research Lab

In article <1992Dec19.192643.19502@news.media.mit.edu>, geek@media.mit.edu (Chris Schmandt) writes:
> In article <1992Dec10.002739.12681@uvm.edu> cavrak@newton.emba.uvm.edu.uvm.edu (Steve Cavrak) writes:
> >
> >2 - Is anyone using ISDN with DECstation 5000 ?  I'd be interested in 
> >finding out about your experiences, setup, etc.
> >
> 
> You can ask your DEC salesperson!!
> Unfortunately I believe the folks responsible for the software have
> all been laid off for a few weeks.  I hope this is not the case, but
> I know other people close to the project who have.
> 
> You'll also see ISDN connectors on the newer Alpha-based workstations.

Yup, the Alpha based workstations also sport basic rate interfaces.

Chris, however, thankfully is not completely correct about the state of the
software project; while the group that housed the ISDN software is being
disbanded, the project itself is continuing (though being moved to New Hampshire)
and we hope to hold onto at least some of the people; this is from a 
conversation I just had with the engineering manager involved.  The project is
pretty far along at this time.

As to when the software will get out the door, on what machines, as it isn't
committed and announced software you'll have to go talk to your Digital Salesman.
				- Jim Gettys

-- 
Digital Equipment Corporation
Cambridge Research Laboratory
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: The ISDN network
Organization: AT&T
Date: Tue, 22 Dec 1992 13:38:24 GMT

In article <1992Dec21.214133.14488@atlastele.com> bcapps@atlastele.com (Brent Capps) writes:
>In article <bob1.724602518@cos> bob1@cos.com (Bob Blackshaw) writes:
>>I was told that the
>>AT&T 5ESS has inbuilt TA to modem pool conversion for just such an
>>event...
>
> The issue is that this 
>service isn't tariffed, and if you called up your friendly RBOC ISDN rep 
>today and tried to order it they would tell you they have no plans to offer 
>it now or at any time in the forseeable future.  
>
>Why?  Because it's a violation of the MFJ.  RBOCs can only provide 
>transmission 
>services and are not allowed to change the content of the info.  The modem 
>pool conversion you suggest has been ruled to violate this restriction. 

Not to necessarily say that there's no regulatory basis for a ban on a
potential BOC modem pool service, but (a) the protocol conversion
restriction was as a result of the FCC's two Computer Inquiries (CI-I and
CI-II); protocol conversion was deemed to be either a "data processing
service" or an "enhanced service", depending on which CI you're talking
about, and could therefore not be offered by (the regulated) AT&T or its
operating companies; how the CIs apply to the divested RBOCs is a good
question... and (b) the information content provision of the MFJ was
remanded to, and subsequently overturned by, the MFJ court.

Of course, if a BOC sees no market for a service, it's not going to face
regulatory battles (or even expend regulatory goodwill) to provide it.

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation
From: dclunie@pax.tpa.com.au (David Clunie)
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN rates
Date: 24 Dec 1992 12:28:56 GMT
Organization: Her Master's Voice
Distribution: world
Reply-To: dclunie@pax.tpa.com.au
NNTP-Posting-Host: britt.pax.tpa.com.au

In article 165394@dstos3.dsto.gov.au, bennett@dstos3.dsto.gov.au () writes:

>dependent. When Telecom set these prices it had a monopoly in Australia. They
>*seem* to compare well with the prices you quote, but it depends on the call
>price structure. 

Do you mean to imply that Optus have plans in the ISDN field ? I would love to
hear about it if they do !

david
From: kph@cisco.com (Kevin Paul Herbert)
Newsgroups: comp.dcom.isdn
Subject: Re: Asynchronous TAs
Date: 23 Dec 1992 19:44:01 GMT
Organization: cisco Systems, Inc., Menlo Park, CA
Distribution: world
NNTP-Posting-Host: cider.cisco.com
Keywords: RS-232 asynch synch 57.6K 56K

The UDS TA supports async DTE speeds up to 57.6K. This is one of the
reasons that I like it.

However, the V.110 rate adaption protocol only goes up to 19.2K. This
is probably the reason that most TAs only go up to 19.2K.

The documentation from UDS says that they use the "T-LINK" protocol for
speeds > 19.2K async. I'm not sure if this is a UDS proprietary protocol,
or if other vendors implement it.

Kevin

Newsgroups: comp.dcom.isdn
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: Re: PPP on multiple B channels
Organization: Morning Star Technologies
Date: Sat, 2 Jan 1993 06:30:46 GMT

In article <2934990872.1.p00136@psilink.com> "Bob Larribeau" <p00136@psilink.com> writes:
   Is there any work going on to define how to support PPP on more
   than one B channel or has this problem already been solved?  The
   most important case is probably to support PPP on 2 B channels.

I believe a subcommittee of the IETF PPP Working Group is working on
the general problem of PPP over more than one link, of which two B
channels is one example.  Write to ietf-ppp@ucdavis.edu for more
information.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)
From: marc@aria.Ascend.COM (Marco S Hyman)
Newsgroups: comp.dcom.isdn
Subject: Re: Switched 56/Switchway .vs. BRI ISDN
Date: 21 Dec 92 16:08:31 GMT
Distribution: na
Organization: Ascend Communications, Alameda, CA

In article <1992Dec18.131156.29780@cbnewsd.cb.att.com> varney@cbnewsd.cb.att.com (Al Varney) writes:
 > In article <1992Dec17.184153.17181@xtcn.com> lamb@xtcn.com (Richard Lamb) writes:
 > >Anyone know if the signalling schemes for the S/T ISDN BRI interface and
 > >the DDS+secondary channel signalling used for switched 56 serivce have
 > >any similarities ? SW56 is bipolar NRZ coding with clock encoded and every
 > >8th bit carrying dialing info.

Richard,

Are you confusing DS0s with SW56?  SW56 is not channel alligned -- there is
no 8th bit for dialing.  It comes in two flavors (that I'm aware of) 2 wire
and 4 wire.  The 2-wire runs the local loop at 144 kbit/s.  Al's post has
the details.  All signaling is in band using various bipolar violation
paterns.  Dialing is via signal transitions, e.g. pulse.

Al says:

 >    On the other hand, Switched 56 interworks well with ISDN in almost
 > all cases.  Bellcore doesn't recognize non-ISDN data in most of the TRs,
 > so there may be some variation among implementations.  If the ISDN TA
 > recognizes 56 kb/s rate adaption and doesn't insist that the far-end
 > has to be "ISDN", there should be little problem interworking.  It's
 > certainly happening today.

We interwork between our AT&T PRI line, PacBell BRI lines, and PacBell SW56
lines with only one minor problem -- a guy/gal goes grey waiting for call
setup when calling from the SW56 side.  Figure a second a digit for dialing
plus other overhead.  10-20 seconds of call setup is not unusual.

// marc
-- 
// work: marc@ascend.com          uunet!aria!marc
// home: marc@dumbcat.sf.ca.us    pacbell!dumbcat!marc    
Newsgroups: comp.dcom.servers
From: cappisk@cuug.ab.ca (Kevin Cappis 283-6333)
Subject: ZMODEM Transfers
Organization: Calgary UNIX User's Group
Distribution: na
Date: Mon, 21 Dec 1992 06:50:38 GMT



We recently posted a problem We were having concerning hardware flow
control with a Datability oem term server. Well, it seems the problem has 
gone away, and I'm ashamed to admit that nobody knows excactly what cured
the problem. The flow control just started to work out of the blue! The
server flow controls just like the manual says it should. 
Thanx anyhow for the replies that came. 

There still is a slight problem with flow control however, and it's not 
an easy to put a finger on.  Several people (pretty much everybody) who 
try to do a ZMODEM tranfer run into a problem where the terminal server
locks up in the middle of the transfer. We can see the cts flow control
functioning properly, and when we do a cat on a large file we don't seem to
experience any lock ups. When the person doing the tranfer gets locked up
he or she hits a break char and gets the server prompt. The next step is
to type "resume" and the transfer continues.

Has anybody had this exact problem? Could it be an escape char such as a
break that's causing the trouble? Could it be an xoff embedded in the 
binary stream? If anybody is doing ZMODEM transfers into a Datability
We'd sure like to hear from you.

Pulling my hair out, Kevin


-- 
\/\/\/\/\/\/\/\/\  Kevin Eric Cappis        * * * * * * * * *
\/\/\/\/\/\/\/\/\/\  125 Abinger Cres. NE     * * * * * * * *
\/\/\/\/\/\/\/\/\/\/\  Calgary Alta. Canada     * * * * * * *
\/\/\/\/\/\/\/\/\/\/\/\  cappisk@sun.cuug.ab.ca   * * * * * *
Date: Fri, 25 Dec 92 10:31:40 EST
From: COM104@UKCC.uky.edu
Newsgroups: comp.dcom.telecom
Subject: Re: ACUTA Services Index-Readable
Organization: TELECOM Digest
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 917, Message 12 of 17

ACUTA has the Index on Pagemaker which if I understand can be
converted to WP.  I can't speak for headquarters but they would
probably sell you a copy of the disk.

ACUTA phone: 606-252-2882  - Del Combs or Bill Robinson