HDTenEightyP/NetNews huggingface dataset:
From: jpsb@NeoSoft.com (Jim Shirreffs)
Subject: Re: The ISDN network
Organization: NeoSoft Communications Services -- (713) 684-5900
Distribution: world 
Date: Sat, 26 Dec 1992 17:32:32 GMT


>Exactly, and if the public would stop chucking bricks and make their
>needs known to the regulators, we might get somewhere. Some of the

I hope you don't mind a "dum" user joining in. 
 
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
that there exists a much better technology but for reasons beyond me
I cann't use it. If a letter would help please tell me who to write.
We will be third rate if we don't provide first rate communications.
 
jim shirreffs
From: dem@fnal.gov (David E. Martin)
Newsgroups: comp.dcom.isdn
Subject: Re: Asynchronous TAs
Date: 23 Dec 92 20:46:09 GMT
Reply-To: dem@fnal.gov
Organization: Fermi National Acclerator Laboratory, Batavia, IL, USA
NNTP-Posting-Host: nhmpw2.fnal.gov

I think that focusing on the RS-232 interface on a PC is wrong.  Almost all
PCs have a much higher speed parallel interface port as well.  I currently
use a Xircom Pocket Ethernet adapter which plugs into the parallel port and
give a thin net connection.  This goes to a Combinet ISDN half-bridge which
gives me dynamic bandwidth allocation at 56 or 112 Kbps.  I tried using 
PPP over via the async at 57.6 Kbps and it beat my PC to death.

David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-8463
P.O. Box 500, MS 368; Batavia, IL 60510  USA   /  \   E-Mail: dem@hep.net
Newsgroups: comp.dcom.isdn
From: bcapps@atlastele.com (Brent Capps)
Subject: Re: The ISDN network
Organization: Atlas Telecom Inc.
Date: Tue, 22 Dec 1992 22:27:32 GMT

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.
-- 
Brent Capps                          | 
bcapps@agora.rain.com (gay stuff)    | Quis corriget correctores ipsos?
bcapps@atlastele.com (telecom stuff) |
Newsgroups: comp.dcom.isdn
From: varney@cbnewsd.cb.att.com (Al Varney)
Subject: Re: The ISDN network
Organization: AT&T
Distribution: na
Date: Thu, 31 Dec 1992 17:29:17 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, and I would be very surprised if the NTI DMS series and 
>>Siemens EWSD are not similarly equipped. Perhaps if there are
>>members of these three companies in this group, they could
>>provide better data.
>
>You have asked the wrong question.  The issue is not whether the DMS/ESS/EWSD 
>switches can technologically do this.  They can.  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. 

   The 5ESS(rg) switch (and maybe others) support both TELCo-owned and
"customer"-owned modem pools for ISDN interworking.  Responsibility for
maintenance can also be designated as "TELCO" or "other".  Just as 3rd
party companies (some with strong ties to a TELCo) can offer voice mail
and pay-per-use services, such companies could offer modem pooling to
the ISDN "public".  And I would agree that modem pooling (which has existed
in Centrex and other situations for a long time) is on the edge of the
MFJ's "info content" provisions.  But a 3rd-party market could easily
develop -- if there was any demand....

>Telcos aren't monolithic entities, and not all segments have greeted ISDN
>with unrestrained joy.  The charge has been made in the past that ISDN has 
>been tariffed artificially high in a deliberate effort to get people *not*
>to use it.  There are certain entrenched groups in the RBOCs who are closely 
>tied to older technologies and whose careers might be threatened if the
>older gear were to be depreciated out ahead of schedule.

   And there are "young Turks" whose advancement may depend on the
success of ISDN.  Like many technologies, the politics (personal,
company, industry and governmental) have more to do with the outcome
than the "logical" merits themselves.  Some have claimed that such
developments take the path that maximizes (short-term) income of the
legal professions, corporate executives and Wall Street.

   I can't argue against that claim -- maybe those are the three fingers
of Adam Smith's "hand"??

Al Varney - just MY opinion.
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: ISDN international tariffs
Organization: Corporation for Open Systems
Distribution: world 
Date: Tue, 22 Dec 1992 14:55:13 GMT

[ arguments and snide remarks deleted ]

Hey Folks, take it easy! In all this debate about 64 kbit/s and 56 kbit/s,
and whether switches work less or more for ISDN, and whether pigs have
wings, we seem to be losing sight of some things.

Today it is a POTS to ISDN transition period, so there will be a few
anomalies in some services.

The 56 kbit/s problem will go away when all T1 systems are converted
to B8ZS line code. However, not all systems are converted and there
will be situations where end-to-end 64 kbit/s cannot be provided. It
is still all digital (no quotes).

Despite the design of the ISDN user-network interface, not all the
processing can be done on the line card (at least I don't see how),
so the switch has more processing overhead. Now most big digital
switches in POTS can handle 80,000 lines or more. I have not heard
any numbers for that same switch machine doing ISDN, but am willing
to bet it is less than under POTS.

In my experience (I spent 33 years with a major carrier), the rates
we are seeing are based partially on the lack of real numbers for
just how much this extra processing will affect the switch capabilities.
When the people who calculate such things get the same sort of data
they now have for POTS, there will be adjustments. The PUCs are not
noted for fast turnaround, so you learn to be careful when filing a
rate package.

$0.02

Bob


Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: The ISDN network
Organization: Corporation for Open Systems
Distribution: world 
Date: Wed, 23 Dec 1992 14:27:16 GMT

In <1992Dec22.133824.9230@cbfsb.cb.att.com> deej@cbnewsf.cb.att.com (david.g.lewis) writes:

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

I once wrote a reply to the FCC on this subject as a consultant. It seems
they still have not learned a damn thing. TA to modem conversion is no
different than analog voice to PCM conversion. What do those beaureau-
crats think happens in analog voice to T1 to T3 transmissions? Hell,
all kinds of conversions take place in the network. What matters is
if an A is input, an A is output. The content is NOT, repeat NOT,
changed. At the rate the FCC is going we will definitely be a third
world country for communications.

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

Exactly, and if the public would stop chucking bricks and make their
needs known to the regulators, we might get somewhere. Some of the
comments I have heard from local PUC people make me believe that they
are living on another planet.

Sorry, but you all hit a nerve.

>David G Lewis                              AT&T Bell Laboratories
>david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation

Bob
Newsgroups: comp.dcom.isdn
From: vances@xenitec.on.ca (Vance Shipley)
Subject: Re: Asynchronous TAs
Organization: SwitchView Inc., Waterloo, Ontario
Date: Thu, 24 Dec 1992 07:46:24 GMT
Keywords: RS-232 asynch synch 57.6K 56K

In article <1hafi1INN170@cronkite.cisco.com> kph@cisco.com (Kevin Paul Herbert) writes:
>The UDS TA supports async DTE speeds up to 57.6K. This is one of the
>reasons that I like it.

I'm glad to hear this, I'll probably buy one soon in this case.  This must
be a new feature because I've chastised them in the past for not having this.

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

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

T-Link is the name of the proprietary, but licenceable, rate adaption
protocol used by Northern Telecom in their Datapath for DMS switched 56K.
It also only specifies asynchronous rates up to 19.2K.  (I have a copy of
this one, it's available because it's public network stuff).

-- 
Vance Shipley 
vances@xenitec.on.ca         vances@switchview.com         vances@ltg.uucp
Newsgroups: comp.dcom.isdn
From: varney@cbnewsd.cb.att.com (Al Varney)
Subject: Re: 5ESS vs GTD5 in relation to ISDN capability
Organization: AT&T Network Systems, Lisle, IL
Distribution: na
Date: Mon, 21 Dec 1992 17:15:29 GMT

 [Repeat of article for some ... sorry.]

In article <BzLnJL.E1H@well.sf.ca.us> nlane@well.sf.ca.us (Nathan D. Lane) writes:
>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?

   Both Northern Telecom and AGCS (the GTD-5 vendor, nee Automatic Electric)
would be upset at any belief that the GTD-5 is associated with Northern.
The 5ESS(rg) switch supports ISDN, but like any current switch, requires
added hardware/memory/software to do so (it's NOT free).  So maybe GTE's
statement was "... OUR 5ESS switch is not set up to do ISDN."

   There are dozens of GTD-5s "talking to" 5ESS switches today, but
unfortunately the GTD-5 switch does not support ISDN lines.  It will
act as a tandem switch for ISDN calls, and I believe it will interwork
switched 56K calls with ISDN connections on other switches.

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

   USERS!!  If it weren't for them, systems would work ever so much better!
(Just kidding -- but telephone folks have an equivalent "caller" saying.)
But you have to realize that "I really need to do NFS and X ..." might
cost something more than normal line charges.  If you are really using
the connection for many hours per day, look into the costs of full-time
connections to another site.  Telecommute savings can justify some pretty
elaborate interconnections.

Al Varney - just MY opinion.


Newsgroups: comp.dcom.isdn
From: "Bob Larribeau" <p00136@psilink.com>
Subject: PPP on multiple B channels
Organization: Consultant
Date: Fri, 1 Jan 1993 19:17:44 GMT
X-Mailer: PSILink-DOS (3.3)

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.

		Bob Larribeau
		San Francisco
From: marc@aria.Ascend.COM (Marco S Hyman)
Newsgroups: comp.dcom.isdn
Subject: Re: Asynchronous TAs
Keywords: RS-232 asynch synch 57.6K 56K
Date: 29 Dec 92 17:13:41 GMT
Organization: Ascend Communications, Alameda, CA

In article <H.eg.37&NepFo9TQ@mips.ruessel.sub.org> naddy@mips.ruessel.sub.org writes:
 > The connection DTE<->TA should run at a commonly supported speed close
 > to or higher than 64kbps, with hardware flow control i.e. RTS/CTS, the
 > TA should bidirectionally buffer the data, strip start/stop bits, and
 > run a standardized HDLC-type protocol (LAPB?) over the ISDN line, This
 > way we also have flow control DCE-DCE, and most important efficient
 > usage of the B channel.

You are describing V.120 rate adaption (almost).  The V.120 spec is a set of
diffs to the Q.921 (LAPD) spec; you need both.

Warning: The handling of end-to-end flow control is not specified.  At least
one manufacturer pays attention to X-on/X-off between DTE and DCE,
converting X-off into RNRs.  At least one other manufacturer pays attention
to X-on/X-off between DTE and DCE, but forwards the X-{on,off} character in
the data stream.  The two types do not interoperate very well.

I don't know of any desktop TA that supports hardware flow control. I don't
know of any that support V.120 at rates higher than 19.2 kbit/s.  Note:
I haven't paid any attention to this aspect of ISDN for well over a year so
my knowledge is probably out of date.

// marc
-- 
// work: marc@ascend.com          uunet!aria!marc
// home: marc@dumbcat.sf.ca.us    pacbell!dumbcat!marc    
Newsgroups: comp.dcom.isdn
From: picone@csc000.csc.ti.com (Joe Picone)
Subject: Terminal Adapters
Originator: picone@csc000
Organization: Tsukuba Research and Development Center
Date: Mon, 28 Dec 1992 20:24:54 GMT

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

Notes:

(1) The annex is a Xylogics Unix box that interfaces multiple serial lines
    to ethernet (for telnet/rlogin services). It handles the multiplexing,
    modem management, etc.

(2) The modems operate at v.32 in an UNCOMPRESSED mode.

Questions:

Can I replace the analog portion (modems/phone lines) with an ISDN
terminal adapter and ISDN telephone line?

If so, please suggest a manufacturer/model no. of the required hardware.

Also, what would be the performance advantage? What if the modems are increased
to 28.8K (v.fast)?

Thanks.


Regards,

----------------------------------------------------             ****
| Joe Picone          | email: picone@trdc.ti.com  |             ****    I
| Texas Instruments   | Phone: +81 298 501738      |             *****T I T***
| Tsukuba R&D Center  | Fax:   +81 298 501729      |          *****TTT I TTT**
| 17 Miyukigaoka      | Msg:   JP27                |           *****TTTTT******
| Tsukuba, Ibaraki    | Alias: "The Terminal Man"  |            *  **********
| Japan 305           |                            |                 *****
----------------------------------------------------                   **

Newsgroups: comp.dcom.isdn
From: bcapps@atlastele.com (Brent Capps)
Subject: Re: The ISDN network
Organization: Atlas Telecom Inc.
Distribution: world 
Date: Mon, 21 Dec 1992 21:41:33 GMT

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, and I would be very surprised if the NTI DMS series and 
>Siemens EWSD are not similarly equipped. Perhaps if there are
>members of these three companies in this group, they could
>provide better data.

I worked on SL-100/DMS-100 CCS7 software development at BNR for several years
during the mid '80s.  

You have asked the wrong question.  The issue is not whether the DMS/ESS/EWSD 
switches can technologically do this.  They can.  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. 

>Regardless of your view or bias toward the telcos, they have been
>running networks for years, so they aren't totally stupid.

Telcos aren't monolithic entities, and not all segments have greeted ISDN
with unrestrained joy.  The charge has been made in the past that ISDN has 
been tariffed artificially high in a deliberate effort to get people *not*
to use it.  There are certain entrenched groups in the RBOCs who are closely 
tied to older technologies and whose careers might be threatened if the
older gear were to be depreciated out ahead of schedule.

-- 
Brent Capps                          | 
bcapps@agora.rain.com (gay stuff)    | Quis corriget correctores ipsos?
bcapps@atlastele.com (telecom stuff) |
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: ISDN international tariffs
Organization: AT&T
Date: Mon, 21 Dec 1992 14:39:21 GMT

In article <BzKv7n.G82@jshark.inet-uk.co.uk> joe@jshark.inet-uk.co.uk (Joe Sharkey) writes:
>In article <1992Dec19.214534.3982@cbnewsd.cb.att.com> varney@cbnewsd.cb.att.com (Al Varney) writes:
>>In article <724643806.AA00663@cswamp.apana.org.au> Arthur@cswamp.apana.org.au (Arthur Marsh) writes:
>>>With one 64 kbps ISDN B channel,
>>>presumably 7500 cps throughput is possible, a five-fold increase
>>>at nearly 3 times the per-minute cost plus a big flagfall.
>>
>>   Where is 7500 cps from???  You should get 64000 bps / 8-bits/c
>
>From the USA'a 56kb "digital" services - look at the rest of what you write.

1.  The quotation marks on the word "digital" are somewhat inflammatory -
56k switched digital services are just as digital as 64k switched digital
services.  They're not ISDN, but then, they don't claim to be.

2.  The original poster was referring to a 64kb/s B-channel.  I am guessing
Al assumed 64kb/s end-to-end, since the original poster made no reference to
rate adaption to 56kb/s, and current standards state that a call with bearer
capability/user service information of 64kb/s UDI, no rate adaption, can be
cleared by the network if no 64kb/s clear channel facilities are available.

>>>Are there other costs to the telephone company involved that
>>>already has ISDN capable equipment that can in any way justify
>>>the extra cost of ISDN?
>
>No. In the UK, ISDN comes in after the codecs, so there is *no* difference.
>Q: Why should I pay more to use *less* of your equipment?  ;)

Because you're not using less of my equipment.  Even looking solely at the
line interface - where your "codecs" are - there's more "equipment"
(hardware and software) for an ISDN interface than an analog loop.  An
analog loop doesn't require a three-layer protocol stack to terminate the
loop...

Disclaimer: It's not really my equipment, since my part of AT&T has nothing
to do with ISDN BRI...
From: bear@cbnewsh.cb.att.com (james.j.allen)
Newsgroups: comp.dcom.isdn
Subject: Re: Asynchronous TAs
Summary: AT&T ISDN Telephone
Keywords: RS-232 asynch synch 57.6K 56K
Date: 29 Dec 92 03:48:53 GMT
Distribution: usa
Organization: AT&T

In article <1992Dec23.192710.3006@xenitec.on.ca>, vances@xenitec.on.ca (Vance Shipley) writes:

> Of all the ISDN terminal adaptors I have seen very few provide asynchronous
> speeds above 19.2K.  None of the TAs I have seen provide faster than 38.4K.

Since early in 1992 AT&T has been selling the 7506 and 7506 API
telephones with a 57.6Kbps EIA-232 asynchronous interface.
This is the AT&T "plain black" ISDN telephone.

The AT&T ISDN telephones use V.120 at 56K or 64K to support these rates.
The phones also support AT&T's DMI Mode 3, Mode 2, and D-Channel
X.25.

Both National ISDN-1 and "classic" AT&T ISDN versions are available.
The NI-1 version works on NI-1 compatible switches (5ESS from
AT&T).  The "classic" version works on 5ESS and AT&T DEFINITY PBX.

The API stands for Application Programmer's Interface.  It allows you
to control the features of the telephone from the attached PC.  You
can answer calls, dial calls, change the ringer, display stuff on
the phone's display.  Contact me for further details.

Sorry for the flag waving -- I am one of the developers :-)

Jim Allen
AT&T ISDN Telephone Development
bear@hocpb.att.com

*5ESS and DEFINITY are trademarks of AT&T
From: co057@cleveland.Freenet.Edu (Steven H. Lichter)
Newsgroups: comp.dcom.isdn
Subject: Re: 5ESS vs GTD5 in relation to ISDN capability
Date: 23 Dec 1992 23:40:09 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu


The GTD-5 which is made by AGCS Communications Systems a joint venture
of AT&T and GTE will work with ISDN when the switch has been updated
to the right issues as will the 5ESS and most other Digital switches.
ISDN to the home is not offered in most areas in California and that
includes both companies. The GTE Smart Parks are now set up for that.
.
Steven H. Lichter COEI
GTE California
.
*******************************************************************************
|                 -=- Sysop: Apple Elite II -=- an Ogg-Net BBS                |
|                   (909) 359-5338  12/24/96/14.4 V32/V42bis                  |
|           Internet co057@cleveland.Freenet.Edu (Steven H. Lichter)          |
*******************************************************************************
Newsgroups: comp.dcom.isdn