Phoenix Rising BBS/phoenixrising.zip/phoenixrising/tele-dig/td14-023.txt

Text File | 1994-01-10 | 26KB | 548 lines

TELECOM Digest     Mon, 10 Jan 94 01:43:00 CST    Volume 14 : Issue 23

Inside This Issue:                          Editor: Patrick A. Townson

    Re: Multi-line BBS's (Lars Poulsen)
    Re: Multi-line BBS's (Fred R. Goldstein)
    Re: Correction: Re: Help Needed With V.42bis ([e-mail])
    Re: Merlin Question (Christopher Zguris)
    Re: US Digital Cellular Standard (Donald J. Miller)
    Re: 500 Channel Cable Television (David M. Berman)
    Re: 500 Channel Cable Television ([e-mail])
    Re: Notice to AT&T Long Distance Customers (Laurence Chiu)
    Re: User Interface From Hell (Gary Bridgewater)
    Re: "Dynamic" SLIP (John Kennedy)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and GEnie.
Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is compilation-copyrighted by Patrick Townson Associates of
Skokie, Illinois USA. We provide telecom consultation services and
long distance resale services including calling cards and 800 numbers.
To reach us:  Post Office Box 1570, Chicago, IL 60690 or by phone
at 708-329-0571 and fax at 708-329-0572. Email: [e-mail].

    ** Article submission address only: [e-mail] **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

TELECOM Digest is gatewayed to Usenet where it appears as the moderated
newsgroup comp.dcom.telecom. It has no connection with the unmoderated
Usenet newsgroup comp.dcom.telecom.tech whose mailing list "Telecom-Tech
Digest" shares archives resources at lcs.mit.edu for the convenience
of users. Please *DO NOT* cross post articles between the groups. All
opinions expressed herein are deemed to be those of the author. Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: [e-mail] (Lars Poulsen)
Subject: Re: Multi-line BBS's
Organization: CMC Network Products, Copenhagen DENMARK
Date: Sun, 9 Jan 94 23:30:05 GMT


In article <[e-mail]> [e-mail]
(Dannie Gregoire) writes:

> I would like to know how some of these bulletin boards have 60-100
> lines running into them (eg EXEC-PC).  Do they simply have that many
> individual lines run or is there a nifty service that the TELCO offers
> through a PBX?

A BBS is just a special case of the general class of "multi-user
computer systems". Access for remote terminal users of such a system
can be provisioned in several ways:

1) If the users are on-site, the system may be constructed with many
   serial ports, and you may wire each terminal directly to a port
   dedicated to that terminal.
   The drawback of this is, that for large systems, serial terminal
   ports may actually be very expensive (as expensive as high-speed
   ports, and probably more expensive than the terminals.)

2) Often the terminals are wired to "cluster controllers" that aggregate
   traffic from a number of terminals (16 is a common number) and feed
   the aggregated traffic into a high-speed port. The operating system
   on the server machine must then contain code to unravel the multiplexed
   data before feeding it into the software driver for the logical ports.

3) If not all of the users are active at the same time, it has been
   common to attach the terminal to a modem, and attach the modem to a
   port on the building's PBX, which then routes the calls to a bank of
   modems which may be attached to ports on the server (as in 1) or on a
   cluster controller (as in 2).

   This allow you to get by with a smaller number of ports, and also
   allows all wiring to be installed by telephone technicians, which
   traditionally have been easier to find and manage than computer
   technicians. Also, the PBX already has mechanisms to deal with
   contention.

4) This technique extends in a simple manner to off-site
   users: Just attach a few modems to outside lines instead of PBX
   station ports.

   You need one outside line with a modem per port, of course.

5) If the callers are far away, you may be able to save by locating the
   cluster controllers near the users, far from the server system,
   and attach them to the server by:
   - leased data lines or
   - automatic dialers that bring the line up when someone needs
     service.

   Generally, if you have a remote building with a cluster, it will  be
   more economical to lease the line. The crossover happens at 2-4
   hours per day. If you have 4 to 8 terminals, then it is likely that at
   any given time at least one will be in use.

6) Some companies have specialized in setting up such remote cluster
   controllers (called PAD: Packet Assembler/Disassembler) provide them
   with local dial-in lines with modems, and arranging for shared carriage
   from these access points to servers in several/many cities over lines
   leased from the phone companies. These companies (legally called
   "Value Added Networks") generally use a protocol called X.25 between
   the cluster controllers and the server hosts. They also provide for
   connections directly between the servers using the X.25 protocol.
   The VAN carriers include CompuServe, SprintNet (formerly TELENET),
   TYMNET, AT&T Accunet, INFONET and many more.
   With such a hookup, you may be able to use a single high-speed access
   line to carry traffic originating at hundreds of different remote
   points.

7) Finally, a whole other group of carriers have sprung up to do the
   same using a more modern set of protocols called TCP/IP or Internet
   Protocol. Generally, this is much less expensive than X.25 service,
   and provides many more features. Principal commercial Internet service
   providers who offer service throughout the USA include: ANS (Advanced
   Networks and Services - a partnership including IBM, MCI and the State
   of Michigan), AlterNET (a service mark of UUNET Technologies), PSI
   (Performance Systems International of Troy, NY), AT&T,  INFONET and
   SprintNet. (At least the last 3 also offer one-stop international
   connections.) The special magic of this technology is that the
   networks are all interconnected, so that your customers can reach you
   even if they have service from different providers.

The company that I work for, is on of many that sells equipment for
Internet service. We expect (between all of us) to hook up every
school and every public library the US and at least Western Europe in
my lifetime. We have a long way to go. To date we have only connected
about two million computers, serving about ten million people
worldwide.


Lars Poulsen                    Internet E-mail:
[e-mail]
CMC Network Products            Phone: (011-) [phone]
Hvidovre Strandvej              72 B    Telefax: [phone]
DK-2650 Hvidovre, DENMARK      Internets: designed and built while you wait

------------------------------

From: [e-mail] (Fred R. Goldstein)
Subject: Re: Multi-line BBS's
Date: 9 Jan 1994 03:18:18 GMT
Organization: Digital Equipment Corp., Littleton MA USA


In article <[e-mail]> [e-mail]
(Dannie Gregoire) writes:

> Hi Pat:

> I'll direct this question to you if possible, as you are the true
> phone system guru.  I asked it in the newsgroup a couple of months
> back with no useful response.  I would like to know how some of these
> bulletin boards have 60-100 lines running into them (eg EXEC-PC).  Do
> they simply have that many individual lines run or is there a nifty
> service that the TELCO offers through a PBX?  I apologize if this is
> a stupid question, but it is one that has baffled me, and I gotta know
> the answer.  Thanks for any help ...

> [TELECOM Digest Editor's Note: Thanks for the compliment, but you
> overestimate my skills a little. Depending on your application or
> needs, you can have as many actual lines run as desired. I suspect
> most very large systems these days however use what is called T-1
> or similar, where a large number of circuits are multiplexed or
> handled over just a few actual pairs of wires. In addition to T-1,
> there are similar methods for bringing in a large number of circuits
> on only a few wires. In my own personal applications in the past,
> I always just had the physical wires, but that was several years
> ago before the present technology became available. Perhaps Fred
> Goldstein or one of the *real* tech people here will reply.   PAT]

I have to admit that I don't know much about how real BBSs operate,
just how they could be operated.  But thanks for the compliment, Pat.

BBSs are funny things.  I read an article about Channel 1, a huge
operation in Cambridge, which services its dozens of incoming lines by
a network of dozens of little PCs.  They were lined up all over a tiny
house.  If it were up to me, I'd have a big machine or two ...

It's often easier and cheaper to use T1 circuits rather than the 23-24
(30 in Europe) separate analog circuits that it replaces.  If your
central office is digital (eg., 5ESS or DMS), then a T1 is much easier
for the phone company to provide -- it plugs right in to a trunk port.
Most large PBXs probably hook up this way now.  For modems, though,
this isn't always cheaper.  You need either a T1 modem (big bucks for
a BBS operator; figure $1k/line, from Primary Access or US Robotics)
or a channel bank (maybe $5k, but available used) to demulitplex it
into analog lines.  Of course you could use a PBX instead but a plain
old channel bank is lots cheaper since it leaves out the switching
function!  So I suspect the BBS crowd tends towards big blocks of
analog lines.

Advantage of moving towards T1: If you're a plain old "kiddiecomms"
BBS, then maybe this won't be necessary.  But if you use T1, you can
not only talk to modems, but talk to ISDN and Switched 56 at a 56 kbps
speed.  Channel banks, PBXs and T1-modems all support this.


Fred R. Goldstein  k1io   [e-mail]
Opinions are mine alone; sharing requires permission

------------------------------

From: [e-mail] (ssatchell on BIX)
Subject: Re: Correction: Re: Help Needed With V.42bis
Date: 8 Jan 94 18:57:34 GMT
Organization: Delphi Internet Services Corporation


Let me add my pair-o'-pennies to the V.42 bis discussion.  Much of
what I'm about to say is derived by my research into the question for
inclusion into TIA PN2826, what will eventually become TSB-38, a modem
testing methodoly description for modems:

BTLZ is not a true LZW derivitive, as jim claims.  (However, the
difference is so minimial that only the truly nitpicking will care.)
It is Ziv-Lempel with several additions to permit adaption and to
prevent expansion of the data, particularly pre-compressed data.  It
also has one of the niftiest escape systems I've ever seen.

You start with a dictionary pre-filled with the alphabet, and have
nine-bit output codes.  As data transfer progresses, and the
dictionary fills, you expand the size of the output code until you
reach the dictionary limit negotiated by both ends.  At that point,
you start "burning" leaf nodes so that as the characteristics of the
data change the LZ tree will change shape to adapt.

If a block of compressed data is significantly larger than its
uncompressed counterpart, then you enter "transparency mode" and send
the uncompressed data.  If a subsequent block of compressed data is
significantly smaller than its uncompressed counterpart, you then
switch to "compression mode".  Initally the system is in transparent
mode.

While in transparent mode, if an escape character is seen, the system
sends an escape-in-data sequence like most codes which use a reserved
flag character.  Unlike the others, though, the escape character
definition is CHANGED so that repeated runs of the (original) escape
character don't cause a two-fold explosion in the size of the
resulting data stream, and a less-than-optimal change to compression
mode for that string.

For PN2826, we wanted to develop test files which would virtually
guarantee one million data bits sent through the signal converter
(before HDLC zero- stuffing).  So we examines a number of files to
determine the compression properties using dictionary sizes common to
modems.

What I found is that the vast majority of uncompressed files
experience a compression ratio (input/output) ranging from 2.5:1 to
3.1:1; the only time I got anywhere near the four-to-one everyone
attributes to V.42 bis is when I was transferring B&W line-art in
uncompressed TIFF form.  (Indeed, with one picture I achieved a 7:1
compression ratio.)

Compressed files had ratios which depended greatly on the scheme used
to com- press them.  LZW-based compressed files showed anywhere from
1.1:1 to 1.4:1 with V.42 bis; a purely random file (generated using
the DES algorithm) has a compression ratio of 0.998:1 -- the expansion
attributed to the 57 escape-in- data sequences in this 132-kilobyte
file.  Encrypted compressed files tended to be at exactly 1:1.

These figures were developed by running files through a desktop
implementation of V.42 bis -- my thanks to Dr. Coleman of Georgia
University for the code.  This is a straightforward implementation of
V.42 bis with a rather wasteful compression prediction algorithm (fill
two buckets, throw out the one that's more full) but is simple and
surprisingly good at minimizing local expansion.

------------------------------

Date: Sun, 9 Jan 94 15:02 EST
From: Christopher Zguris <[e-mail]>
Subject: Re: Merlin Question


In a recent TELECOM Digest post Vince Dugar ([e-mail].
com) wrote:

> Why does the Merlin system charge users so much (I forget now, but
> it's a lot) to buy a special modem adapter?  Is there a cheaper
> solution?  What about using an acoustic modem? (only want it for
> CompuServe mail handling, so low baud would be OK)

  The simplest way I know of - that I have used successfully - is to
tap the voice pair on the merlin. As I remember, the voice pair on the
merlin are the two middle wires on the 8 pin jack. If you're
electronically inclined (or know someone who is) the simple schematic
below should do the trick. To build it, you'll need two identical
RJ-45 8-position 8-conductor phone jacks, and another merlin cable. To
build it, wire pins 1-3 and 6-8 straight through from the "from Wall"
jack to the "to phone". Tap pins 4 & 5 with a cable to plug into the
modem (or run them to another jack and plug the modem in). The SPST
switch is optional, but will come in handy, read on.  To use the
thing, plug the cord coming from the wall in the "from wall" jack and
plug your new cord into the "to phone" jack, then plug that cord into
your phone. You're phone should work fine, if it doesn't, disconnect
the gizmo and check you're wiring. To actually use the thing, fire up
your modem, dial out, and QUICKLY pick up on a line USING the merlin
phone. When the modem dials it will dial out through the merlin on
whatever line your merlin has selected! The disadvantage to this gizmo
over the AT&T rip-off is that you must keep the merlin off-hook while
your modem is in use and manually hang up when your modem is done
(redialling is impossible- if you want to do that manually dial and
redial using the merlin). You will want to set the SPST switch to open
so the voice pair disconnected from the merlin, otherwise the modem
noise will come through the merlin speaker or handset, and if the
handset it used voices and noises will be picked up and sent and screw
up your modem communications. I've used a similar setup at 2400 baud,
anything above that I can't vouch for. When you're done, flip the SPST
switch. If you have any questions let me know, I'll try to help out- I
love solving problems!

          {From Wall}
    1  2  3  4  5  6  7  8
   [;][;][;][;][;][;][;][;] 8 Position-8 Cond. RJ-45 Jack
    I  I  I  I  I  I  I  I
             I  I
             I  I
             *---------------------- \
             I  I                      TAP-wire to modem (red & Green)
             I  *------------------- /
             I  I
             I  I
             I  I-------------O /
             I                 /  SPST Switch
             I  I-------------O
             I  I
             I  I
    I  I  I  I  I  I  I  I
   [;][;][;][;][;][;][;][;] 8 Position-8 Cond. RJ-45 Jack
         {To Phone}

(First attempt at ASCII art, what do you think?)


Chris

------------------------------

From: [e-mail] (Donald J. Miller)
Subject: Re: US Digital Cellular Standard
Date: 9 Jan 1994 13:59:23 -0800
Organization: CRL Dialup Internet Access        [phone]  [login: guest]


Weiyun Yu ([e-mail]) wrote:

> It has come to my attention that the digital cellular standards
> adopted by US carriers are not going to be compatible with what we
> have adopted in Australia, GSM. I am interested in finding out a bit
> more about the US systems but cant find any FAQ on the subject.

The US Digital Cellular scheme (TDMA) was originally conceived to ease
the bandwidth requirement for a phone conversation by at least 3 to 1.
A 6 to 1 capacity advantage over the regular AMPS service would be
achieved if and when acceptable half-rate voice codecs were available.
Currently, each caall uses two of the six TDMA time slots.  The aim
was/is to eventually use only one.

The first TDMA phones were to be dual-mode: that is to say that they
would function as regular AMPS phones as well.  The hope WAS that
after 10 to 15 years, the AMPS functionality could be dropped,
resulting in more cost effective phones.  A monkey wrench has been
tossed in the works, however.

AFTER the cellular industry chose TDMA as the standard, Qualcomm
proposed the use of a different CDMA technology with promises of even
greater capacity.  Some, but not all carriers joined the Qualcomm
camp.  The net result is that we now have two digital phone standards.

Motorola proposed a new analog system (NAMPS) with a capacity
advantage of 3 to 1 over AMPS that many hail as a good intermediate
step before full digital cellular implementation.

So, now we have FOUR phone "standards".  What about ROAMING?

Well, it looks like the more expensive DUAL-MODE phones are here to
stay.  Either of the two digital systems, TDMA or CDMA could have been
cost effective with time and further work on the ICs inside the
phones.  The power-wasting RF duplexers required in AMPS phones for
full-duplex operation would not have been needed -- money would be
saved and talk time increased.

Six times the existing bandwidth was not enough.  We got greedy.


Don Miller    [e-mail]

------------------------------

From: [e-mail] (David M. Berman)
Subject: Re: 500 Channel Cable Television
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Sun, 9 Jan 1994 18:46:22 GMT


I think most of you are limiting yourselves when you imagine the
offerings that could be available with video dial-tone or 5000
channels of audio/video/data.  Imagine not only every piece of video,
film, or music ever published, but the new publishing opportunities
that will spring from recent advances in home/cheap video and audio
production.  You might see excellent products aimed at smaller and
smaller audiences (college lectures, poems, paintings, dance, how to
fix your 1983 Toyota, etc.).  To me, the most exciting thing about the
possibility of all this new bandwith is the thought that we could
escape the tyranny of the majority and their pedestrian tastes.


David M. Berman   [e-mail]

------------------------------

From: [e-mail]
Subject: Re: 500 Channel Cable Television
Date: Sun, 9 Jan 94 22:51:21 EST
Organization: Delphi Internet


I somewhat agree.  Who has the most bandwidth in the home? Anyone of
the 500 channels could be an on-demand channel. By the way, without a
broadband entry in the house how can all of the consumers requests be
met like pix in pix.

------------------------------

From: [e-mail] (Laurence Chiu)
Subject: Re: Notice to AT&T Long Distance Customers
Date: 9 Jan 1994 20:24:23 -0800
Organization: CRL Dialup Internet Access, California
Reply-To: [e-mail]


In article <[e-mail]>, William M. Eldridge wrote:

>> According to a wire service account in the {Boston Globe}, AT&T is
>> changing their rates to be more like MCI and Sprint.  The list price

> As somebody who just switched from AT&T to MCI, I have a few
> qualifications for this.

> On international calls, MCI has all weekend rates, while AT&T leaves
> its three Day-Evening-Night slots the same, seven days a week.  MCI
> has better hours during the week.  AT&T had worse setup (first minute)
> charges.

If you join Reach Out World from AT&T for $3 a month, then it seems
that there are only two time slots and there is no higher first minute
charge. It's quite competitive with MCI now, Friends and Family even
taken into account. For example if I specifiy New Zealand as my
Selected Country then during off peak times and weekends I get to call
*any* number in NZ for 0.68/minute while with MCI and their Friends
around the World plan and Friends and Family, I get to call only a
maximum of two numbers for $0.66/minute. I find AT&T's plan more
flexible here.


Laurence Chiu         | Walnut Creek, California
Tel: [phone](wk) | Internet: [e-mail]

------------------------------

From: [e-mail] (Gary Bridgewater)
Subject: Re: User Interface From Hell
Date: 9 Jan 1994 08:41:39 GMT
Organization: LSI Logic


In article <[e-mail]> [e-mail]
(John Limpert) writes:

> How can telephones be made easier to use?  The local phone companies
> are going to have a hard time selling new features to their customers
> if they expect them to press "*-*-FLASH-4-2-#-6-6-6" every time they
> use them.

In another life, at a super-mini company, we had a subsidiary PBX
design company that was designing a terminal/phone combo but the whole
thing evaporated during a "rightsizing".  I saw one working - real,
not a prototype.  There was a button on the terminal keypad that would
bring up a phone menu and you could click on the option you wanted.
Software on the computer could interact with the phone so you could
have a Rolodex on-line and touch a number to dial it, record and
playback digital messages and record and playback on-line (with a
beep).  You could then file, mail, etc. the messages.  Took lots (and
lots) of disk space but we sold disks so what the heck.  Used realy
cheap off-shore digital handsets - bad but liveable.  Probably
something like the Newton will solve this.  Also, the VCR programming
in another thread.


Gary Bridgewater ([e-mail]) LSI Logic, Milpitas, CA

------------------------------

From: [e-mail] (John Kennedy)
Subject: Re: "Dynamic" SLIP
Date: 9 Jan 1994 18:52:35 GMT
Organization: California State University, Chico


In article <[e-mail]>, <[e-mail]> wrote:

> My understanding of SLIP is that it is a point-to-point dedicated
> configuration, requiring a modem on the receiving end to be dedicated
> to a specific user (due to IP I think).

  If you get the right hardware, that isn't necessarily true.  You
could dedicate one line/SLIP connection if you wanted to, but many
people don't.

  Most people dedicate one IP _addresses_ to a SLIP user.  That mostly
depends on how much you're willing to trust any IP address (for
security purposes or otherwise ... like access to a USENET server).

>  I've heard some talk about so-called 'dynamic' SLIP -- where the SLIP
>  connection is made, but through a mux or terminal server, allowing the
>  provider to serve multiple dial-up customers instead of a 1-1 ratio. ...

  Yes, true.  I use Cisco communication servers to do this, but there
are many more vendors that provide the same features.  Depending on
your computer's OS, you might be able to connect a modem into it and
server multiple SLIP users.

  The one thing I'd worry about is that most SLIP servers I've seen
can only provide access to the subnet they are in ...  so you can only
server ~250 (fixed, single user/IP addr) users with one rotary.


John Kennedy <[e-mail]>;   Communications Services;   USENET admin

------------------------------

End of TELECOM Digest V14 #23
*****************************