From: varney@cbnewsd.cb.att.com (Al Varney)
Subject: Re: Obtaining ISDN
Organization: AT&T Network Systems, Lisle, IL
Distribution: usa
Date: Thu, 19 Nov 1992 06:13:52 GMT

In article <1992Nov16.235427.11813@advtech.uswest.com> huntting@advtech.uswest.com (Brad Huntting) writes:
>In article <1992Nov13.154757.28389@bmerh85.bnr.ca> coghlan@bnr.ca (Patrick Coghlan) writes:
>>[With ISDN at home] you would have:
>
>>- a 64 k/bit data line which does not interfere with your use of the 
>>  telephone
>
>As opposed to a 14.4Kb/s real throughput on a single POTS line.  For us
>realistic folks it's really more like ~35Kb/s when you include V.42bis
>compression.  Of course now I'll be flamed by the half of the group for
>comparring apples and oranges again, but in the real world it's
>perfectly reasonable to compare these because you cant buy ISDN with
>compression.  (Or did I miss something?)

   Your POTS line doesn't have compression either -- you bought the
CPE with compression.  I realize it's hard to keep the CPE features
distinct from the ISDN line services, but try ... the CPE features
will certainly exhibit the same falling-cost effects observed in
modems, PCs, etc.

   Nothing prevents you from pre-compressing your data or running an
output stream that compresses on the fly (with a real OS).  If there
is a market demand, I'm sure Hayes, et. al. will be happy to fill it
-- but you'd better be ready for something like V.35 instead of RS-232
for 3X compression onto 64Kbps channels (or 3X onto 2 B-channels).
And don't forget that ISDN B-channels are 64Kbps BI-DIRECTIONAL;
there are lots of applications that aren't "happy" with 14.4Kbps in
just one direction.

>>- use of the X.25 protocol over this data line which can be used to
>>  set up multiple sessions simultaneously
>
>Has anyone tested this in the real world?  Can your local switch deal
>with X.25 traffic at a reasonable rate (if at all)?  How many virtual
>X.25 connections can you multiplex on one B channel?

   Tested??  We've been using it for over 2 years, and I'm sure
there are others as well.  Our primary data application is just
X.25 over D-channel from a high percentage of 10,000+ ISDN sets.
But much of that is routed over "permanent packet" B-channels
connected to X.25-compatible packet switches or to X.25 front-ends
of large mainframes.  The current switch limit on D-channel X.25 is
8 logical channels, but the B-channel limit is much higher (either
128 or 256 -- Documents are at work).  Typically, you would be
very unhappy with the grade of service with even 256 9.6Kbps
D-channels multiplexed onto 1 B-channel.  That's why there are
TELCo controls on max. X.25 logical channels per B-channel, and
why it makes sense to assign popular destinations to larger
hunt groups (multiple B-chanels) or high-speed X.75 connections.
(If you have a good application with 256 channels and average
demand of only 256 bps, 1 B-channel might be great!).

>> It should also be much cheaper to dial-up over long-distance than using
>> telephones and modems since the charges for holding time on packet
>> networks are much less than for voice...  I think.
>
>Really?  Could some of the folks who work for interLATA carier's
>comment on this creative billing mechanism?  This is the first I've
>heard of it.  I find it hard to believe that an ISDN call could be
>anything but more expencive than an POTS call.  But if you were being
>billed by the packet then it could make sence.

   While I work for AT&T, it's not the "interLATA carrier" part
of the company, so billing is out of my area.  The ISDN switches
(the major ones, anyway) generate lots of usage information for
X.25 and ISDN calls.  How the LECs, etc. use it is up to them and
the PUCs.  If the X.75 interface is used, the added cost to the
TELCos is mostly in the (shared) processors used to do X.25
forwarding to an X.75 connection.  Dialing up a far-end ISDN
set and then using X.25 for a single logical connection doesn't
make sense, however

   For circuit-switched data calls, ISDN just gives you a 64Kbps
(or 56Kbps) connection to far-end CPE.  You can run any protocol
(or none).  You can even connect a modem and a good ADC and convert
the modem analog output to 64Kbps data.  Or multiplex 4 voice
connections with voice compression.

>Of course this presuposes that your local RBOC and your longdistance
>carrier can pass ISDN traffic...  I dont honestly know if U S WEST has
>that capability with any longdistance provider yet.  What would it
>take?  SS7?

   SS7 isn't needed to connect most ISDN switches to an X.25
packet network (via X.75).  But circuit-switched 64Kbps will
require SS7 interfaces.  Circuit-switched 56Kbps is possible
today without SS7, but is iffy if you don't dial it as a
"Switched 56" or similar data call.  ISDN will also connect to
or accept calls from existing analog "Switched 56" users.

>IDSN offers speed, but requires outragously high priced customer
>premise equipment.  So you can get either 35Kb/s out of a second phone
>line for $17/mo with a $300 modem, or 64Kb/s (mabey 128Kb/s) out of an
>ISDN line which you also use as your primary telephone for $X/mo with
>about $2000+ worth of equipment (unless you have a NeXT, a Sparc10 at
>home).
>
>Now how if you are going to shell out that extra $1700+ for the
>hardware to use ISDN (on both ends of the connection probably!), then
>what do you suppose X would have to be to make up for it?

   I don't know -- isn't "X" a random variable?  Seriously, about
6 years ago, I'll bet the same argument was made about those $1000
9600bps modems.  "Who needs'em?  My $300 1200bps modem works fine!!
Why spend the extra money?"

Al Varney - just MY opinion.
Newsgroups: comp.dcom.isdn