Telecom/1996-04-telecom-walnutcreek.iso/back.issues/recent.single.issues/V15_#536

Internet Message Format | 1995-12-28 | 30.8 KB

From [e-mail]  Fri Dec 29 01:44:12 1995
Return-Path: <[e-mail]>
Received: by massis.lcs.mit.edu (8.7.1/NSCS-1.0S)
    id BAA13492; Fri, 29 Dec 1995 01:44:12 -0500 (EST)
Date: Fri, 29 Dec 1995 01:44:12 -0500 (EST)
From: [e-mail] (Patrick A. Townson)
Message-Id: <[e-mail]>
To: [e-mail]
Bcc:
Subject: TELECOM Digest V15 #536

TELECOM Digest     Fri, 29 Dec 95 01:44:00 EST    Volume 15 : Issue 536

Inside This Issue:                           Editor: Patrick A. Townson

    Re: SMDR Data Available? (Jose Cordones)
    Re: ITA Dating Service Rip Off: Is This a Scam? (Shubu Mukherjee)
    Re: ITA Dating Service Rip Off: Is This a Scam? (Dave Levenson)
    Suggestions For PC Voicemail Software? (Mickey Ferguson)
    Want to Buy: Old Telephone Set (Daniel Rosenberg)
    Re: D3 Channel Bank Question (Pat Martin)
    Re: MFJ vs. Internet Development (Steve Cogorno)
    Re: Warning: SLC96 Cannot do 28.8 kbps (Pat Martin)
    Re: "PCS Faces Rough Road" (Pat Martin)
    Re: Time Limits on 800 Calls From a Pay Phone? (D. Brent)
    The Day The Bell System Died (Lauren Weinstein/TD 1983 Reprint)

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 America
On Line. It is also gatewayed to Usenet where it appears as the moderated
newsgroup 'comp.dcom.telecom'.

Subscriptions are available to qualified organizations and individual
readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax
or phone at:
                      Post Office Box 4621
                     Skokie, IL USA   60076
                       Phone: [phone]
                        Fax: [phone]
  ** Article submission address: [e-mail]

Our archives are located at ftp.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 partially funded by a grant from the              *
* International Telecommunication Union (ITU) in Geneva, Switzerland    *
* under the aegis of its Telecom Information Exchange Services (TIES)   *
* project.  Views expressed herein should not be construed as represent-*
* ing views of the ITU.                                                 *
*************************************************************************

     In addition, TELECOM Digest receives a grant from Microsoft
     to assist with publication expenses. Editorial content in
     the Digest is totally independent, and does not necessarily
     represent the views of Microsoft.
     ------------------------------------------------------------

Finally, the Digest is funded by gifts from generous readers such as
yourself who provide funding in amounts deemed appropriate. Your help
is important and appreciated. A suggested donation of twenty dollars
per year per reader is considered appropriate. See our address above.

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] (Jose Cordones)
Subject: Re: SMDR Data Available?
Date: 28 Dec 1995 20:31:18 -0500
Organization: spacelab.net Internet Access


Doug Smith ([e-mail]) wrote:
[clip]

>> 2. If the answer to 1. is negative, what are my options for extending the
>> capabilities of some "simple" PBX such as the AT&T Partner by connecting
>> it to a PC.  For example, if I wished to have a system where a caller is
>> identified with CID, looked up on a database, offered a voice prompt
>> [for a PIN #], and if they match, give clearance to call.  Alas, if I

> On the Toshiba, it only outputs SMDR data when the call is completed
> or transferred so that it can contain the final time.  This makes it
> impossible to do any intellegent call routing or database lookup at
> the start of a call.  I know this is true with some other systems as
> well.  I once heard of a company that put every caller on hold and
> transferred them in order to capture the SMDR.

Doug,

I did some RTFM'ing with the manual for the AT&T Partner II and like
you and others pointed out, it's pretty much obvious that SMDR data
varies across models, let alone vendor.  Bad Thing(tm).  For that
particular ailment, I am thinking of a configurable parser that
basically is specified its legal inputs by a language grammar.

As for the delivery time of the SMDR data, it is quite braindead, so
the information is dumped to you some time after the call is
completed.  Like I had suspected in my first posting, it seems I will
have to hack an interface compatible with a System phone.  Why, you
ask?  SMDR is really lousy for the parts where I would like to:

1. authenticate caller at beginning of transaction.
2. have more or less real time limits on the phone usage for each user,
and to boot, most users will be remote.

OTOH, System Stations are given CID info by the PBX (when properly
set-up, of course) if they are the ones that pick-up the call.  Let me
avoid confussion by defining that "system" refers to the computer,
System Station refers to sort of the super-user PBX extensions (exts.
10 and 11 on the Partner), interface refers to the device to be built.

The System Station/interface's ability to read CID info on inbound
calls takes care of reqirement 1.  I feel that I can safely make the
assumption that as long as SMDR doesn't spit out an entry for a given
call, the call is in progress.  So, that trick takes care of
reqirement 2.  Even if SMDR is "late" by a few seconds in giving me
the information at the end of a particular call, I should have a timer
on the system for that on-going transaction.  If, for example, the
time reaches the user's limit, it doesn't matter that SMDR hasn't spit
out the info, my timer says it is past due.  Finally, when SMDR does
print the info, I have the actual PBX time at which the call was
ended.  So, SDMR is good as a sanity-checker, but the actual
accounting needs to be done with some kind of interfacing that behaves
like a System Phone.  Other capabilities I'd need to add include
touch-tone detection, for PIN verification and perhaps manual entering
of "originating" telephone numbers on "Out of Area," etc. types of
inbound calls; Recorded-prompts (on some voice-EPROMS?) to play back,
etc. would be nice.

To recap: the user calls up the PBX, which is routing all the calls to
the station(s) controlled/signalled by the phone system; The system
CID's the user and looks up the PIN for that user.  The user is
prompted for PIN. If CID number and PIN number match a pair in the
database, access is granted.  User now has rights to a line.
Basically, the system is the one receiving the numnber to be dialed
from the user, so it needs to decode it.

Once decoded, it dials the number for the user on a second line and
joins them (possibly by CONFerencing them or by transfering the caller
to the same line as the callee.  Depends on the PBX.  Once they are
joined, the call is said to be in progress and the counters are
happily running and the system is guarding the user's allowed time
(limits are imposed, etc. so a long distance call cost database is
needed).

So far, I only know that I have quite some RTFM'ing ahead of me for
months to come.  It seems there's pretty much an IC for every use out
there, and if there's none, there's one very close to it.  So far I
have seen a book (title escapes me) with basic projects in Electronics
for Telephony, and a series of articles in Electronics-Now that
cleverly use some ICs.  It seems my recourse is to comb the IC Master
Manuals and find chips with capabilities "close" to my task, but this
is bound to be tedious and error-prone.  Does anyone have more direct
recommendations on books (from beginner to advanced) about Telephony
Projects, about the common Telephony electronic parts, etc.  Perhaps a
version of the IC Master Manual only with Telephony stuff?

As for TAPI, TSPI, etc.  I had read Intel's homepages and it was of no
help.  I now have checked Microsoft's TAPI page and they actually
bother to provide info.  From the Intel disinformation part, my
fingers itched to tell you "but I want the computer to control many
lines, not one ..." but I just found a paper (ftp://ftp.microsoft.com/
developr/TAPI/CLTSRV.ZIP) that claims "dispells the belief that TAPI
can't do third party call control and gives a suggestion on how to
impliment both the client and the server TAPI components."  The format
seems to be "Power Point Text[?]" and I can't read it, though :-/
Are there other any advanced books out on TAPI, even if from Microsoft
or Intel?  A friend tells me that Apple has a Telephony API, too, but
I don't know any more, at this time.  I'll be hunting.  Any comments?

I don't have the manual for the Partner II on me but I volunteer to
collate a file of SDMR formats as reported by other readers and by PBX
models/manuals I run across.  Any takers?  Just quote the page where
SDMR is described on your manual and I'll quote it directly on that
file.  Soon we should have a fairly decent SDMR file and it can be
made available over FTP.  So that we save bandwidth, mail your entries
to [e-mail].  Questions about the status of the file,
too.  You will be entirely credited as having submitted your entries.

It seems this is going to be a lot of fun, I'll keep you posted.


Jose Cordones <[e-mail]>

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

From: [e-mail] (Shubu Mukherjee)
Subject: Re: ITA Dating Service Rip Off: Is This a Scam?
Date: 29 Dec 1995 01:35:33 GMT
Organization: CS Department, University of Wisconsin


> [TELECOM Digest Editor's Note: But you *did* call their number.
> You said so yourself.

Never!  :-) Don't jump to conclusions.  Never ever did I say that any
where in my posts.  We called them ___after___ we received our bill.
Clear?

If you still doubt it, check my previous posts and show me where I
said so.

> we know you called them and how long you were on the line,

Aren't you being a bit judgmental?


Shubu Mukherjee        Univeristy of Wisconsin-Madison, Computer Sciences
[e-mail]      http://www.cs.wisc.edu/~shubu


[TELECOM Digest Editor's Note: Well okay ... let's let it pass for now
with my wishes to you for a Happy New Year.    PAT]

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

From: [e-mail] (Dave Levenson)
Subject: Re: ITA Dating Service Rip Off: Is This a Scam?
Organization: Westmark, Inc.
Date: Fri, 29 Dec 1995 01:26:51 GMT


Our moderator writes:

> [TELECOM Digest Editor's Note: Well, the adult/sex IP's out there *claim*
> they give ample notification of their charges. They *claim* that if you
> remain on the line you do so of your volition and with full knowledge
> of the cost of the call, and your consent for billing.

The problem comes when the rightful owner of the billed telephone is
not the one on the line.  PBX-owners, payphone owners, and others who
make telephone service available to the public are in serious trouble
under Pat's rationalization.  If calling an 800 number can result in
charges to the calling party, then it is no longer safe to allow the
public to call 800 numbers.  How useful is an 800 number if it can
only be called from residence lines?


Dave Levenson        Internet: [e-mail]
Westmark, Inc.        UUCP: uunet!westmark!dave
Stirling, NJ, USA    Voice: 908 647 0900  Fax: [phone]


[TELECOM Digest Editor's Note: I think you will find however that
most of these funny numbers actually are non-dialable from pay phones.
Whenever I find an 800 number of the kind we have been discussing,
I always try it from a payphone, and preferably a COCOT style payphone
just to see how smart the COCOT proprietor and the information provider
are. If the call goes through, I say fine ... because I think there
should be a plague on both their houses. But time and again, genuine
Bell payphones *never* complete those calls, even if it is an 800
number, because the information provider has access to a database
of phone numbers listed as being in coin service. Quite a few of
the COCOTS are listed that way as well, or else the COCOT owner has
deliberatly listed himself on the negative list at Integratel, etc.
So while your argument sounds good and makes sense, in real life the
800's 'which charge the caller' never can complete from anything but
a private residence. Remember the horoscope people about three years
ago we experimented with? They were the only ones I've ever seen who
did not have themselves covered where pay phones were concerned.  PAT]

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

From: Mickey Ferguson <[e-mail]>
Subject: Suggestions For PC Voicemail Software?
Date: Thu, 28 Dec 1995 18:11:42 +0000
Organization: Stac


I've got my brand-new Pentium-75 at home running Win95 (OK, no major
workhorse, but quite a step up from my old 386SX-25!).  I'd like to
find a nice program to handle my answering machine types of functions
at home.  Nothing too fancy, just something to use my modem to answer
the call and store it on my PC hard disk, and then I can retrieve my
messages either at my leisure from my desk, or maybe even retrieve
them remotely by entering some kind of access code.  Any suggestions?
Of course, price is also a consideration!  (Of COURSE!  <g>)

I'll summarize my responses if there is any interest (and I get any
good alternatives).

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

From: [e-mail] (Daniel Rosenberg)
Subject: Want to Buy: Old Telephone Set
Date: 29 Dec 95 02:53:14 GMT
Organization: Stanford University


Hi folks --

    I'm looking for individuals or companies that sell old
telephone sets, since I got it into my head that something like
a genuine Western Electric 200 set (or near equivalent) would make
a great gift for my friends with flaky cordless phones.

    If you know of anyone willing to part with one or two of these
beasts, please email me, or phone at 908 464 5269. While I cannot pay
the prices quoted to me in New York City antique boutiques, I'm
willing to part with a reasonable amount for working equipment. By
mail is okay, but individuals or stores in or near Philadelphia, New
Jersey, New York, New England, or Salt Lake City (where I'll be for
the week of 31 Dec-6 Jan) would be preferred.


Thanks,

Daniel Rosenberg, KZSU Radio
http://kzsu.Stanford.EDU/~dmr/

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

From: [e-mail] (Pat Martin)
Subject: Re: D3 Channel Bank Question
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Fri, 29 Dec 1995 04:13:11 GMT


In article <[e-mail]>, edshuck@visual-traffic.
com (Edward Shuck) wrote:

> On Wed, 27 Dec 1995 04:52:40 GMT, [e-mail] (Raymon A.
> Bobbitt) wrote:

>> Does anyone know the difference between D3 and D4 framing in a channel
>> bank??

>> I have six D# units and was wondering what I can use them for.

> I have a little experience with this.  Years ago I worked at TRW
> Vidar.  The D3 will work against a D4 set to mode 3.  The D4 will
> handle two D3s in this configuration.

Yeah, correct me if I am wrong, but is not a D4 bank just a single
bank with two full D3 banks built in, often sharing timing and or some
of the CE?  Most of the old dumb banks are sold this way.

There was also the optional tranmission of T2 over copper which sent
both D3 signal down the same set of pairs, but I do not know if that
was D4.


Patrick L. Martin       [e-mail]

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

From: [e-mail] (Steve Cogorno)
Subject: Re: MFJ vs. Internet Develpoment
Date: Thu, 28 Dec 1995 20:29:50 -0800 (PST)


TELECOM Digest Editor noted:

> Oh, but you said 'internet' with a lower-case /i/ instead of 'Internet'
> with an upper-case /I/ didn't you ... and there is a difference!
> They are two different things. Upper-case Internet consists of the
> traditional 'domains' ie. .edu, .mil, .gov, .com and .org and it
> was originally the system which interconnected universities and
> the government/military research institutions, etc.  Lower-case
> internet on the other hand is ... well, for lack of a better term,
> the rest of you who have interconnected with the above over the years.

Actually that's not quite right.  The "Internet" is what we are using
to communicate right now; an "internet" (with a lower case i) is *any*
two (or more) networks that are interconnected.  If there's a router,
then there's an internet.

But back to the original question: the Internet as we know it was in
existence long before divestiutre, but on a much smaller scale.  The
'Net originally came about when the Pentagon had a surplus to spend.
The military had (maybe has?) a special unit to dispose of 'unused'
cash so that congress can't get it back.  It's called the Advanced
Research Projects Agency, or ARPA.  The net that was developed was
called ARPANet.  Basically it linked research universities and military
bases.  The TCP and IP protocols were designed specifically for
ARPAnet, and in the early days IP was severly limited.  The routing
protocols used the Distributed Bellman Ford algorithm.  Although it is
simple to implement, it has some serious looping errors that can cause
throughput to drop to a miniscule fraction of the link's bandwidth.

Since ARPANet used leased lines and satellite links, I don't really
believe that divestiture had much to do with the explosion of the
internet. (As I understand it, rates for leased lines did not drop
nearly as much as consumer long distance prices.)  From a technological
standpoint, the physical communication channels haven't changed much at
all.  T1 and T3 lines are still the main backbones between ISPs.

I believe that the "real" cause of the Internet explosion is that the
price of modems and personal computers has dropped dramatically while
the speed and power has greatly increased.


Steve    [e-mail]

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

From: [e-mail] (Pat Martin)
Subject: Re: Warning: SLC96 Cannot do 28.8 kbps
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Fri, 29 Dec 1995 04:28:00 GMT


In article <[e-mail]>, [e-mail]
(Bryan Halvorson) wrote:

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

>> The issue with the SLC-96 and V.34 (28.8) modems is actually one more
>> directly attributable to the use of D4 framing and AMI line coding
>> than blaming the SLC itself.  If the telco will cooperate in setting
>> the SLC up to use Extended Superframe and Binary 8-zero substitution
>> (ESF/B8ZS) then you'll miraculously begin to see lots of 28,800 bps
>> connections.
<snip>
>> It would help the situation if the telco can provide full "integration"
>> of the SLC at the Central Office end (meaning the T1 channels of the
>> SLC are switched digitally in the CO without breaking down to analog
>> ahead of the switch).  Unfortunately this isn't possible if the CO
>> itself is an analog machine.

B8zs and ESF really won't buy any quality improvement for voice
tranmission.  Voice codecs can be set so that an all zero code is
never generated thus ensuring bit density in T1 tranmission as there
is at least one bit set in each byte. This reduces the number of
availible byte codes by 1, from a possible 256 to a possible 255. The
impact on voice quality is virtually non-existant.

Standard T1 signalling does bit rob certain frames for signalling.
Though this does not occur on every frame I have heard of some quality
impact. B8ZS and ESF, however, have no impact on this. The only way to
get around this is to use some type of 'out of band' signalling like
ISDN or CC7.

If the SLC is configurable for out of band this might help (I know
little about SLC-96). I would suspect that the old problem of running
digital to the CO and then interfacing to the switch via analog is
most likely the culprit.  We T1 delivered CO trunks here in Houston
which go through that rigamarole.


Patrick L. Martin       [e-mail]

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

From: [e-mail] (Pat Martin)
Subject: Re: "PCS Faces Rough Road"
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Fri, 29 Dec 1995 04:05:24 GMT


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

> An interesting article appeared in the {Globe and Mail} (Canada) regarding
> the future of PCS.  The author, Geoffrey Rowan, appears to cast doubt
> on the viability of PCS providers; he maintains that cellular technology
> will not be quickly missplaced for the following reasons:

> 1)  PCS phones cannot compete with cellular phones on price since they are
> practically giving away cell phones;

> 2)  PCS air time cannot compete with cellular air time charges since most
> cellular companies are not charging on evenings and weekends;

> 3)  PCS phones cannot be practically any more portable than the latest
> cell phones;

> 4)  PCS phones will not work in moving vehicles.

> Mr. Rowan questions why the PCS industry would spend billions in
> infrastructure to duplicate services that already exist.

> Is there merit to these arguments, and do the same conditions apply in
> the United States (given that millions have already been spent on
> licenses)?

Add to that -

PCS providers will have to pay additional millions, or billions, to
move Private Microwave users out of the 1.9 ghz bands before they can
go on the air with their systems.

However -

PCS companies have lots and lots of money. The big boys like ATT,
Sprint, and all of the baby bells have bought in to PCS heavily. Most
of the PCS companies are partnerships of big boys like the
aforementioned.

PCS companies figure to drop the per minute prices an order of
magnitude and thus generate an order of magnitude of additional market
penetration. What if an average per minute price drop of 50% occurs?
What if that generates 10 times more customers?

ATT and some of the other big boys plan to market nation wide services
which use PCS in some areas and cellular in others. All with the same
telephone. No more roaming, anywhere in the country call in or out for
the standard per minute rate. I call you wherever you are, no extra
charge -- for you or me.

Some are hinting that the monthly cost of a PCS phone will eventually
average about the same as the monthly cost of a wired phone. What
about the market penetration then?

PCS phones will be able to work in moving vehicles. Propagation at 1.9
ghz will be more iffy than with 800 mhz, so the signal saturation will
have to be higher to ensure equivelant reliability. A properly
designed system can meet or exceed current Cellular reliability.

Finally -

One thing is certain, no one can really predict what the technological
world will look like in the next fifty or so years. I once scoffed at
the idea that we would pay to have TV delivered via cable, I won't
make that mistake again.


Patrick L. Martin       [e-mail]

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

From: [e-mail] (DBrent8971)
Subject: Re: Time Limits on 800 Calls From a Pay Phone?
Date: 28 Dec 1995 18:42:56 -0500
Organization: America Online, Inc. (1-800-827-6364)
Reply-To: [e-mail] (DBrent8971)


> What occurred to me is that NYNEX is limiting call duration because of
> the traditionally high usage of pay phones in train stations, when the
> call is an 800 call.  Does this seem plausible?

First, are you sure it was a NYNEX phone?  Some COCOTs limit the
number of digits you can dial.  This is a fraud protection issue to
prevent DDD calls from being billed to their phone.  If you were able
to obtain several quotes via DTMF inputs and then the pad went dead, I
assume you exceeded the limit.

NYNEX makes access $ from the IXC for every minute you spend on the
800 call, so they would have no reason to disconnect your call.

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

Date: Fri, 29 Dec 1995 00:30:52 EST
From: TELECOM Digest Editor <[e-mail]>
Subject: The Day The Bell System Died


As we approach the end of another year, we remember the divestiture of
the Bell System with mixed feelings. Now finishing the twelfth year of
post 'Ma Bell' attitudes, we've seen much discussin in the Digest over
the years of 'what might have been', 'what really happened', etc.

Long time -- in fact, charter -- subscriber/reader Lauren Weinstein
sent in a message in 1983 which has since become a traditional classic
here at the end of every year.

This message first appeared in TELECOM Digest in mid-July, 1983 when
divestiture was six months underway. Here it is again ...

   ** DO NOT use the addresses shown here to contact Lauren. They
      are all long since obsolete **

  12-Jul-83 09:14:32-PDT,4930;000000000001
  Return-path: <@LBL-CSAM:vortex!lauren@LBL-CSAM>
  Received: from LBL-CSAM by USC-ECLB; Tue 12 Jul 83 09:12:46-PDT
  Date: Tuesday, 12-Jul-83 01:18:19-PDT
  From: Lauren Weinstein <vortex!lauren@LBL-CSAM>
  Subject: "The Day Bell System Died"
  Return-Path: <vortex!lauren@LBL-CSAM>
  Message-Id: <[e-mail]>
  Received: by LBL-CSAM.ARPA (3.327/3.21)
    id AA17341; 12 Jul 83 09:14:35 PDT (Tue)
  To: TELECOM@ECLB

Greetings.  With the massive changes now taking place in the
telecommunications industry, we're all being inundated with seemingly
endless news items and points of information regarding the various
effects now beginning to take place.  However, one important element
has been missing: a song!  Since the great Tom Lehrer has retired from
the composing world, I will now attempt to fill this void with my own
light-hearted, non-serious look at a possible future of telecommunica-
tions.  This work is entirely satirical, and none of its lyrics are
meant to be interpreted in a non-satirical manner.  The song should be
sung to the tune of Don Mclean's classic "American Pie".  I call my
version "The Day Bell System Died"...

 --Lauren--

**************************************************************************

           *==================================*
           * Notice: This is a satirical work *
           *==================================*


                    "The Day Bell System Died"


              Lyrics Copyright (C) 1983 by Lauren Weinstein

                      (To the tune of "American Pie")

             (With apologies to Don McLean)


  ARPA: vortex!lauren@LBL-CSAM
  UUCP: {decvax, ihnp4, harpo, ucbvax!lbl-csam, randvax}!vortex!lauren

**************************************************************************

Long, long, time ago,
I can still remember,
When the local calls were "free".
And I knew if I paid my bill,
And never wished them any ill,
That the phone company would let me be...

But Uncle Sam said he knew better,
Split 'em up, for all and ever!
We'll foster competition:
It's good capital-ism!

I can't remember if I cried,
When my phone bill first tripled in size.
But something touched me deep inside,
The day... Bell System... died.

And we were singing...

Bye, bye, Ma Bell, why did you die?
We get static from Sprint and echo from MCI,
"Our local calls have us in hock!" we all cry.
Oh Ma Bell why did you have to die?
Ma Bell why did you have to die?

Is your office Step by Step,
Or have you gotten some Crossbar yet?
Everybody used to ask...
Oh, is TSPS coming soon?
IDDD will be a boon!
And, I hope to get a Touch-Tone phone, real soon...

The color phones are really neat,
And direct dialing can't be beat!
My area code is "low":
The prestige way to go!

Oh, they just raised phone booths to a dime!
Well, I suppose it's about time.
I remember how the payphones chimed,
The day... Bell System... died.

And we were singing...

Bye, bye, Ma Bell, why did you die?
We get static from Sprint and echo from MCI,
"Our local calls have us in hock!" we all cry.
Oh Ma Bell why did you have to die?
Ma Bell why did you have to die?

Back then we were all at one rate,
Phone installs didn't cause debate,
About who'd put which wire where...
Installers came right out to you,
No "phone stores" with their ballyhoo,
And 411 was free, seemed very fair!

But FCC wanted it seems,
To let others skim long-distance creams,
No matter 'bout the locals,
They're mostly all just yokels!

And so one day it came to pass,
That the great Bell System did collapse,
In rubble now, we all do mass,
The day... Bell System... died.

So bye, bye, Ma Bell, why did you die?
We get static from Sprint and echo from MCI,
"Our local calls have us in hock!" we all cry.
Oh Ma Bell why did you have to die?
Ma Bell why did you have to die?

I drove on out to Murray Hill,
To see Bell Labs, some time to kill,
But the sign there said the Labs were gone.
I went back to my old CO,
Where I'd had my phone lines, years ago,
But it was empty, dark, and ever so forlorn...

No relays pulsed,
No data crooned,
No MF tones did play their tunes,
There wasn't a word spoken,
All carrier paths were broken...

And so that's how it all occurred,
Microwave horns just nests for birds,
Everything became so absurd,
The day... Bell System... died.

So bye, bye, Ma Bell, why did you die?
We get static from Sprint and echo from MCI,
"Our local calls have us in hock!" we all cry.
Oh Ma Bell why did you have to die?
Ma Bell why did you have to die?

We were singing:

Bye, bye, Ma Bell, why did you die?
We get static from Sprint and echo from MCI,
"Our local calls have us in hock!" we all cry.
Oh Ma Bell why did you have to die?

<End>

                   =======================

[TELECOM Editor's Note: Ma Bell died December 31, 1982. Long live
Ma Bell! A little later today to finish out the present year a new
essay from George Gilder will be distributed and you'll receive my
increasingly frequent request for your annual voluntary donation
to help keep the Digest alive for another year unless you want to
see this Digest go the way of Ma Bell; and I do not mean I'll be
so wealthy and powerful and all-pervasive that I will be required
to divest myself ... <grin, or should that be a frown> ...

Then, over the holiday weekend a few more special mailings will
come out to you including the new 1996 Frequently Asked Questions
File (FAQ) for comp.dcom.telecom, an updated guide/index to the
Telecom Archives with a help file for its use, and an index to
the authors and subjects which appeared in the Digest during 1995.
Sometime early next week we'll start Volume 16 in this continuing
discussion on telecommunications and life in general.   PAT]

              HAPPY   NEW  YEAR  TO  ALL  !!
              =====   ===  ====  ==  ===  ==

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

End of TELECOM Digest V15 #536
******************************