From: John De Armond
Subject: Re: Can an AOS Masquerade as MCI?
Date: 30 Aug 89 13:51:01 GMT
Organization: Sales Technologies Inc., "The Procedure IS the product"

v7fs1!mvp@apple.com (Mike Van Pelt) writes:
>Suppose you just flatly refuse to pay any charges that come from an
>AOS?  

Important point I forgot to mention.  The customer service area was right
out side our development area.  I frequently observed them in action.
The policy was to refund almost any charge unless it was a blantant 
attempt at cheating.  Their philosophy was that the business was so 
profitable that they could afford to give a few bogus refunds rather
than risk having someone complain to authorities.  You should keep this
in mind if you ever get an AOS bill.

>Make sure that you place no calls unless the operator says
>"BOINGGGGGgggg AT&T." Then when the AOS bills you, you can confidently
>tell them "I did not place any such call through your company.  I never
>place calls from (hotels, pay phones, etc.) through anyone but AT&T,
>and I ALWAYS make sure the operator SAYS AT&T.  (Or MCI, Sprint, or
>whatever.)  This charge is, therefore, obviously fraudulent.  Carbon
>copy the FCC or whoever else would be interested in this kind of
>criminal activity.

NO, you cannot make that claim.  We synthesized the bong and other 
AT&T call progress sounds exactly (Easy to do with a dsp board in
a PC.  In case any of you are wondering about my ethics, I was told
that they had an agreement with AT&T on this subject.)  The operators
were trained to use the data we presented them and analyze the call
as to profit potential.  If the call could not be easily billed or
did not appear to be profitable, it was handed off to AT&T - after
trapping out the AT&T operator's greeting, of course.

Your best defense, after boycotting all AOS facilities of course, is 
to ask the operator explicitly who they work for.  Even this AOS would not
direct the operators to lie to such a direct question.  And of course,
complain like hell if you get a bill from any of these sharks.

Yes, this stuff is illegal now, but then, so is odometer rollback.  Both
both still happen.  Until AOSs are outlawed alltogether, these problems
will continue to exist.  The problem is that since AOS operations are
akin to printing money, it attracted the same class of people one might
find in a counterfeiting operation.

(Then, in response to another correspondent)

miket@brspyr1.brs.com (Mike Trout) writes:

>I just received my new MCI card (actually, just the same as the old one; this
>one gives five miles on Northwest Airlines per dollar spent on MCI), and there
>was some interesting accompanying literature.

>In "The MCI/Northwest WORLDPERKS Card Wallet Guide to long distance calling":

>"Use your MCI/Northwest WORLDPERKS Card Around Town...Make long distance or
>international calls from a touch-tone phone in your local calling area.  Your
>calls will be free of the normal surcharge imposed by long distance carriers.
>Or from your hotel...First dial 9, or the appropriate number to get an outside
>local line.  Then dial 950-1022.  This way you will not be charged by the hotel
>for your long distance calls."

NO, NO, NO, NO, a thousand times, NO.  This WILL NOT work in facilities that
are signed up with an AOS that cheats - which is what we're worried about.
The AOS has total control over your environment.  How much control they
choose to exercise is up to them.

Let's review how this works.  Consider a motel environment.  The motel has
a PBX that handles room calls.  The PBX also connects to a few POTS lines
for placing 9+ and 8+ numbers.  The PBX handles routing your call to the 
line and in some cases, charging your room for the call.

When an AOS comes in, they break the POTS lines and insert smart dialers.
These devices look a lot like modems and are designed to redirect
calls placed through them.  The smart dialer traps the numbers the PBX
outputs and disposes of them according to how they were programmed.
In the system I worked with, the smartdialer trapped the subscriber's numbers
and then dialed an 800 number connected to our switch.  The smartdialer then
outputs the trapped numbers.  The call is processed by the AOS switch.
In our case, even local calls were routed to the switch and redialed LONG
DISTANCE (That they could get away with this shows how profitable this is).
This was specifically designed to prevent users from dialing the 950- or
800- access numbers and bypassing the AOS.

Yes, this practice is illegal and yes it still exists.

Caller beware!

John

From: "John G. De Armond" <rsiatl!jgd@gatech.edu>
Subject: Re: Sprint Stuff
Date: 28 Jan 90 09:56:22 GMT
Reply-To: "John G. De Armond" <rsiatl!jgd@gatech.edu>
Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car 
 and gun works facility)

>The amusing thing about this is that up until recently, when keying in
>my Pac*Bell card to an AOS, they would generally reject the call
>saying that my card number was "invalid". (It had no phone number that
>they could sleaze casual billing to.) Lately, however, I am noticing
>that they seem to be able to verify the number, and if I change one
>digit in the "PIN", they reject it. This means that they either have
>access to the great calling card database in the sky, or they are
>sleazing some sort of "test call" that uses the number and "listens"
>for a Pac*Bell or AT&T rejection. (Didn't some AOS get sued by AT&T
>for this?)

The reason for this is simple.  All visa/MC/Amex type and the phone
company credit cards ("phone company" means most BOC or AT&T) follow a
published standard of checksuming the digits of the card.  The last
digit is a derived value based a computation of a sum-of-the-digits
algorithm.  This algorithm is not a simple add-the-digits routine but
I don't have the specifics handy.

One of 2 things has happened.  Either Pac*Bell has changed to a
standard algorithm or they've published the one they use so the AOS's
can verify.  I suspect the later.  For the AOS's I'm familiar with,
the algorithmic check is ALL they do.  They don't subscribe to or use
a credit database.

Another interesting fact concerns the insecurity of PINs.  We already
know that the last digit is computed.  On most AT&T/BOC cards, the PIN
starts with a "2".  (Please don't clog the group here telling me that
yours is different.  I make my statement based on some pretty reliable
statistics we collected when I was working with an AOS.)  This leaves
only 2 numbers to "guess" if you are trying to figure out a PIN.  This
is something you might want to keep in mind as you review your phone
charges.


John De Armond, WD4OQC                     | The Fano Factor - 
Radiation Systems, Inc.     Atlanta, GA    | Where Theory meets Reality.
emory!rsiatl!jgd          **I am the NRA** | 

Reply-To: John Higdon <john@bovine.ati.com>
Subject: Re: Sprint Stuff
Date: 28 Jan 90 23:47:45 PST (Sun)
From: John Higdon <john@bovine.ati.com>

"John G. De Armond" <rsiatl!jgd@gatech.edu> writes:

> On most AT&T/BOC cards, the PIN
> starts with a "2".  (Please don't clog the group here telling me that
> yours is different.  I make my statement based on some pretty reliable
> statistics we collected when I was working with an AOS.)

I don't mean to be a pill, but I have five (5) separate BOC calling
cards on completely separate accounts. The PINs start with "1", "3",
"4", "5", and "9". Trust me; I'm sitting here looking at them all
lined up in a row.

Now that's hardly a scientific cross section, but zero out of five
would tend to discount the statement that "2" is some magic number,
wouldn't you say?

        John Higdon         |   P. O. Box 7648   |   +1 408 723 1395
    john@bovine.ati.com     | San Jose, CA 95150 |       M o o !


[Moderator's Note: Speaking of same, I just checked out my Illinois
Bell Calling Card (which I prefer over the AT&T card with the same
number, because the graphics on the IBT card are nicer). My PIN starts
with a '3'. I have a copy of my parent's AT&T card (they are serviced
by Southwestern Bell, but use the actual AT&T plastic), and it begins
with a '5'. Maybe he meant to say most do NOT start with '2'. :)  On
the other hand, maybe he was illustrating how reliable most <A>sinine
<O>perator <S>ervices in verifying who they bill.   PT]

From: "John G. De Armond" <rsiatl!jgd@gatech.edu>
Subject: Calling Card Numbers (was Re: Sprint Stuff)
Date: 1 Feb 90 19:45:17 GMT
Reply-To: "John G. De Armond" <rsiatl!jgd@gatech.edu>
Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and 
 gun works facility)

In article <3386@accuvax.nwu.edu> comcon!roy@uunet.uu.net (Roy M. Silvernail) 
writes:

>> Another interesting fact concerns the insecurity of PINs.  We already
>> know that the last digit is computed.  On most AT&T/BOC cards, the PIN
>> starts with a "2".  

>Alaska PINs don't seem to start with '2', and both of my 4-digit PINs
>have different beginning digits.

I've gotten several comments on this subject.  My comments regarding
the pin starting with "2" is as a result of looking at perhaps 50,000
transactions in the 1988 timeframe.  The AOS I was contracted to
served primarily Georgia and Tennessee.  The overwhelming majority of
pins from this area started with "2".  I'd like to think that the fact
that peoples' pins are different now means that someone woke up and
realized the exposure.

>Does this mean that if I were to compute a 'logically correct'
>14-digit CC number, I could slip it by the AOS sleazeballs? (not that
>I'm planning it, but.....:-)

Yep, sure does.  At least with the AOS operators I'm familiar with,
they do NOT rent a subscriber database from a carrier or access it.
The trick that some have used of placing a test call to AT&T is now
clearly not permitted so the algorithm verification is probably all
they do.


John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress-
Radiation Systems, Inc. | men than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
emory!rsiatl!jgd        |  - Dr. W Williams |                **I am the NRA**  

From: John De Armond
Subject: The Way I Built and Operated an AOS
Date: 24 Jun 91 05:53:37 GMT
Organization: Dixie Comm, The South's First Commercial Public Access Unix

jim@equi.com (Jim Allard) writes:

Preface to comments:

Several years ago one other engineer and myself designed and built the
switching system for an AOS.  The name will not be mentioned because
quite frankly I can't prove everything to legal standards that I'm
going to discuss.  I will use this experience as the basis of my
comments.  Nor will I provide any further technical details, as these
could be used to identify the AOS.

I will also apologize in advance to those who have been cheated by the
system I constructed.  My 20-20 hindsight leads me to believe that we
were selected to implement this system because we knew little about
the practices of the long distance business.

I know nothing of Jim Allard's company other than what's contained in
his post.  I commend him for his company's practices.  The AOS I
worked for is definately NOT his.  However his defense of AOS systems
falls on deaf ears.  His is a minority of what I suspect to be one.

> 1.  Hasn't anyone noticed that AT&T LD rates have dropped dramatically
> since divestiture?  Does anyone really believe they (AT&T) would have
> done that on their own?  If you had a monopoly, would you?  Wake up
> and smell the coffee ... competition among other things have been
> responsible for more realistic pricing in the LD market.  There has
> also been an increase in charges for local service (not necessarily
> corresponding but understandable).

And for which we can thank MCI and Sprint.  Since most AOSes tack on
many dollars in charges over and above the mileage and per-minute
rate, they cannot by any stretch of the imagination be considered to
have applied competative price pressure to AT&T.

> 3.  Every public IXC except AT&T provides 800 or 950 access to their
> network as a convenience to their customers.  AT&T steadfastly sticks
> to 10XXX as the ONLY means for non-subscribed customer access (or
> access by their customers from non-AT&T phones).  If you owned 200
> switches at your hotel chain, would you give guests unrestricted fraud
> potential?

> Fact is, it cost us $1500 per switch to allow guests full AT&T
> capability with fraud protection.  We spent the money because some of
> our clients' guests like AT&T ... go figure, but we believe in
> service.  Interestingly, only 5% of our AOS customers ask for other
> carriers, a percentage of that for AT&T.  We carefully provide
> instructions for access to the caller's carrier of choice and various
> other alternative billing methods.  95% of our callers CHOOSE to use
> us.  And yes, we clearly brand our service at the beginning and end of
> our involvement (which we've been doing since well before it was law).
> This based on two years of handling greater than 400,000 calls per
> month.

> 4.  This business of an AOS connecting callers to the AT&T network is
> a joke.  While we can technologically do so, they refuse to take the
> call, claiming possible fraud and high error concerns as some of their
> reasoning.  It would be a nice service to 'their' customers, and we
> would have to pay origination charges for the entire length of the
> call.  Their position reminds me of the kid who takes his ball and
> goes home if you don't want to play by his rules.

Here is the meat of the problem.  AT&T was forced to adopt these
policies.  While not a supporter of AT&T I do understand why they have
become hardnosed.  Let me outline some things we did at the AOS.  And
we were not alone.

If a motel or other institution signed up with us, the first step was
to install redirectors (devices that receive touchtone digits, store
them, dial another number and regurgitate the digits) on all outgoing
lines.  These redirectors were programed to dial an 800 number into
our switch.  In most cases, we even intercepted local calls -- dialed
via LD back to the local area -- in an effort to block ALL access to
other carriers.

Our switch received the numbers and tried to complete the call if
possible by redirecting it out a channel on the T.  If it failed or if
operator assistance was required, the call was directed to an operator
workstation.  Our software interpreted the prefix digits if any (ex:
10288) and posted a message on the terminal as to what brand the
operator was supposed to emulate.  If 10288 was dialed, the operator
was supposed to sound like an At&T operator.  The women were given
intensive training as to how to slur the phrase (ex: "T'N'T) so that
they were not exactly being technically fraudulent.  Whatever the
desired carrier, the call was processed and billed by us with all the
charges added on.

The next issue was credit card validation.  There are two levels of
credit card validation.  The first and most simple is algorithmic and
the second is verifying that the account is good and the charges can
be applied.

The various credit granting companies and TPC all charge significant
fees for credit card validation.  Our bunch decided on a much cheaper
way.

All credit cards (except some now-obsolete AT&T business accounts)
have checksums built into the account number.  Each vendor (Visa, MC,
AT&T, etc) use different algorithms but we knew them all.  Most credit
card vendors are identified by the first digit of the number.  The AOS
decided that since the profits were so high, they could forgoe most
actual account validation and only perform the algorithmic check.
They reasoned that they could eat the few bad accounts.

There was one exception.  AT&T/BOC calling cards.  When our software
received such a number, the switch grabbed an outgoing line, dialed an
internal LD number using 10288, listened for the bong, fired off the
PIN and listened for the response.  If a "thank you" (digitized sound
pattern matching) was heard, the credit card number was considered
validated and the AT&T connection was terminated.  Our switch then
completed and billed the call through our trunks.  If any other
response was detected, the operator was given an approrpriate message.

If the operator got such a message or if she wanted to not handle the
call for any other reason, she could hit a function key which would
put some simulated switching audio out to the caller while the call
was dialed to 10288.  Our software listened for the AT&T operator
voice and upon the first silence thereafter, cut the caller over.  The
caller would likely never know he was using an AT&T operator.  This
was before the AT&T operators were taught to thank the customer.  Even
if he did, he would likely not know anything about AOS systems and
would not be confused about the duplicate operators.  In any event, we
tried to bill the call too if possible.  Thus the customer would get
two bills for the same call, one from us and one from AT&T.  Over 90%
of the customers would pay the charge without question!  What sheep we
are.

We were shown what I now believe to be forged documentation that
indicated there was an agreement with AT&T to do this.  I wondered at
the time why we did not just tie directly to AT&T's system.

Since our switch could churn out thousands of such "validation" calls
per day, it had a huge impact on AT&T.  Unfortunately AT&T made this
task too easy with the nice bong and digitized voice messages that
never changed.

I know from discussions with people from other AOS companies that we
were not the only ones doing this kind of "validation".  I've observed
that AT&T rarely does anything unless forced.  The AOS industry forced
them to revise their messages and their policies.

> 5.  My company DOES NOT apply any additional surcharges to calls we
> handle, even though it's legal in many states and for interstate
> traffic.  The same stipulation is in every contract we write.  Our
> rates mirror AT&T's.  We guarantee not to charge more than their
> standard time-of-day discounted rates.  In fact, our billing programs
> round down (not up) to ensure compliance with the policy.  Yes, we
> also issue immediate credit for mis-dialed calls.

I'm really glad to hear that.  You are the exception.  Most companies
round up and some do worse.  By "rounding up", I mean that if a call
lasts four minutes and five seconds, it is legal to round that call to
five minutes.  At my AOS, I was told by the DP manager that their
billing software (as opposed to my switching software) automatically
added a minute to each call AFTER rounding.  I think some attorney
generals have had something to say about that practice.  My AOS would
also let the institution add any amount they wanted to as a "trade
surcharge".  Motels typically added $5.  If a customer complained
about any aspect of service, the policy was to automatically give
credit. They reasoned that it was bad to attract attention plus since
the profits were so high, it did not matter.

> Is AT&T deliberately designing a card system which will create serious
> customer dissatisfaction in an effort to pressure aggregators into
> presubscribing to AT&T?  I don't think the last legal shot has been
> fired on this issue and I hope the public isn't that gullible.

No, I think AT&T is trying to come up with a system that will not too
terribly inconvenience their customers while preventing scumbag AOS
and COCOT operators from abusing their billing and validation system.
The tragedy is that we all lose from this experience.

> I sincerely hope this does not come off sounding like a whining
> step-child.  We expect to be successful or fail on our own merits.  If
> we can provide the service at reasonable costs to the calling public,
> on a level playing field, I say let the market determine the winners
> and losers.  Keep the politicians out of it, or we'll end up with
> three LD phone companies about five years from now.  That's not what I
> call choice, and the playing field is far from level.

You don't come across as whining but at the same time if the
government shut down every agregator in the nation I'd be very happy.
If someone else wants to build a physical plant and enter into the
fray with AT&T, MCI and Sprint, I'd more than welcome it.  The
resellers are a whole 'nuther matter all together.

Note to the net.nitpickers.  NO I'm not a telephone professional.  I
knew enough about telephony to recognize a T from a local loop but I
know little about long distance.  Which is probably why I got the job.
I got a crash course in the art while working on the system but that
does not an expert make.  If I use terminology incorrectly ... sue me  :-)


[Moderator's Note: Gee whiz ... and over on eff.talk not long ago you
said  ** I ** was an asshole ??  If you notice a snall difference
between what you submitted and what I printed its because I removed
your parenthetical gay-bashing remarks about AT&T employees.    PAT]

Subject: Kidnapped by Goons from the Mob! (DeArmond Builds AOS)
Date: 26 Jun 91 23:25:43 EDT (Wed)
From: Larry Lippman <kitty!larry@uunet.uu.net>

	In a recent article <telecom11.487.1@eecs.nwu.edu> John G.
DeArmond (emory!Dixie.Com!jgd@gatech.edu) spins an amusing yarn about
his alleged involvement with an AOS operation.

	Unfortunately, Mr. DeArmond left out some of the *best* parts
of his alleged adventure -- which he told in a somewhat different
fashion to readers of misc.jobs.contract about a year ago.  So as to
not deprive Telecom readers of this additional entertainment, I have
reproduced this previous article below.  I'll add a few comments at
the end.

$$> >From sunybcs!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!
    rsiatl!jgd Thu Jul 19 22:14:43 EDT 1990
$$> Path: sunybcs!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!
    rsiatl!jgd
$$> >From: jgd@rsiatl.UUCP (John G. DeArmond)
$$> Newsgroups: misc.jobs.contract
$$> Subject: Re: Timebombs (was Sueing your client for collection)
$$> Message-ID: <3204@rsiatl.UUCP>
$$> Date: 15 Jul 90 07:55:15 GMT
$$> References: <25191@bellcore.bellcore.com> <3150@rsiatl.UUCP>
    <23411@boulder.Colorado.EDU> <1990Jul13.193639.22253@ecn.purdue.edu>
$$> Distribution: misc
$$> Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and
    gun works facility)
$$> Lines: 66
$$> 
    [some non-relevant text deleted]
$$> 
$$> We had a client for which we were implementing an operator-assisted
$$> long distance switch.  We were subbing through a prime contractor 
$$> who had a contract with the client that would pay us a royality based
$$> on the generated revenue from the system.  It was a sweetheart deal
$$> for all involved and relations could not have been better.  We 
$$> were paid at the end of every week with checks that never bounced.
$$> We were working in office space subleased from the client - a 
$$> necessity in order to be close to the switch and trunks.
$$> 
$$> Just as we were turning up the first system, the founders of this
$$> startup phone company sold the company.  The new owner was, shall
$$> we say, unsavory.  He decided that he did not want to pay royalities
$$> or allow us to own the program -which we had the right to.  So he 
$$> addressed the problem in the usual mob manner - he sent some goons over
$$> to kidnap us while they stole our equipment and software.  
$$> 
$$> Sure we sued them and pressed criminal charges.  But in America today,
$$> money is justice (and don't ever forget that.)  He managed to have the
$$> criminal charges quietly dropped and the civil case, though still
$$> technically on the docket now 5 years later, is effectively dead.
$$> He simply out-moneyed us.  We got nothing and he got to use our 
$$> system.  We kept our source code encrypted so he did not get that, though
$$> at one point, he almost had a judge convinced to issue an injuction
$$> to force us to reveal the password.  Think of the intellectual property
$$> implications of that move.
$$> 
$$> What he got was a system that worked and would carry the load for 
$$> a sufficient period of time to have his programmers reverse-engineer
$$> it.  If we had included a timebomb in the system from the very 
$$> first, he would have been denied the use of the stolen system and 
$$> would have had to bargan with us instead of blungeoning us with
$$> lawyers.
$$> 
$$> It is unfortunate that human nature makes people like you take the 
$$> moral high ground without having ever experienced the other side.
$$> Until you actually do have to face a lose-lose situation, 
$$> you really can't predict all outcomes or appreciate how something
$$> like a timebomb, which you might not like, is vastly better than
$$> the alternative.
$$> 
$$> John
$$> 
$$> -- 
$$> John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
$$> Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
$$> Atlanta, Ga             | provide broker services for their customers.
$$> {emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**  
                        
                          -------------

	By golly, what a tale!  Mr. DeArmond was "kidnapped by goons
from the mob"!

	It is also amusing to note that in the previous telling of
this tale Mr. DeArmond relates it as a "sweetheart deal" because he
would allegedly stand to receive a percentage of the revenue.  Not
exactly the same condemnation of AOS fraud in the earlier version of
the tale, is there?

> Several years ago one other engineer and myself designed and built the
> switching system for an AOS.  The name will not be mentioned because
> quite frankly I can't prove everything to legal standards that I'm
> going to discuss.  I will use this experience as the basis of my
> comments.  Nor will I provide any further technical details, as these
> could be used to identify the AOS.

	Why the secrecy?  If the story is true, then the alleged
criminal court proccedings and alleged civil court proceedings are a
matter of public record.

	Surely it would bolster Mr. DeArmond's credibility if he were
to furnish a few more identifying details -- after all this could be
THE AOS ADVENTURE STORY OF THE DECADE!

	Wanna bet there are no further details, because, well, there
just may not have been any ...


Larry Lippman @ Recognition Research Corp.  
VOICE: 716/688-1231       {boulder, rutgers, watmath}!ub!kitty!larry
FAX:   716/741-9635   [note: ub=acsu.buffalo.edu] uunet!/      \aerion!larry


[Moderator's Note: I was amused by the several notes I received saying
I was wrong for calling him a Naughty Word, and I'll admit that was
sort of out of place here ... but it really was a wild story a year
ago, and the most recent incantation was pretty hysterical also.  PAT]

From: John Higdon <john@zygot.ati.com>
Subject: AOS is not like 976!
Date: 30 Aug 89 23:11:44 GMT
Organization: Green Hills and Cows

In article <telecom-v09i0334m02@vector.dallas.tx.us>, john@zygot.ati.com 
(John Higdon) writes:
> BTW, I've got a little AOS horror story in the works. The final event
> should occur tomorrow. If the information I've received checks out, it
> could all be a little worse than we imagined.

Well, here it is. On my last phone bill there were some AOS charges
from Honolulu to San Jose that were bogus from a company called "Long
Distance America". A quick call to the business office to have them
removed followed, of course. The Pac*Bell person said, "Just a moment
while I see what the agreement is with them. Oh, OK, I can remove those
calls for you and give you a credit."

So what, you say? It suddenly hit me: could there be something in the
agreement that would prevent them giving me a credit? What? How would
it work? A little investigation turned up the following.

Every single carrier that does business with Pac*Bell (and by
extension, its customers) has an individual contract on file. This
contract specifies type of billing, amounts, and *how much, if any,
latitude Pac*Bell has in adjusting billed amounts*. If you make a lot
of 976 calls and you convince Pac*Bell that you shouldn't be
responsible for them, PB can simply remove them from your bill and
charge back the information provider, no questions asked. Not
necessarily so with LD carriers.

For instance, the following is a real possibility. You open your
Pac*Bell bill and discover over $1,000 in long distance billed by
Fly-By-Night Telecom. None of those numbers look familier and you know
that you never spent any time in Thistle, Utah. So you call PB. The
lady is very sympathetic, but informs you that there is nothing she can
do about the charges; that you must take it up with FBN directly. She
gives you FBN's number and its a standard number in New York. You call
them collect, but they refuse the charges. So you pay AT&T for the
call. After they put you on hold and transfer you to several different
people, someone finally tells you that their equipment couldn't be
wrong and that you owe the money.

The controlling governmental body, the FCC, doesn't want to hear about
it. The state PUC is powerless because it is interstate traffic.
Pacific Bell will not disconnect your service if you don't pay that
portion, they are not going to want to get involved in your fight with
FBN. Meanwhile, there are those LD calls to the FBN headquarters.

My friend at PB said that the above story happens constantly, in some
form or another. Just when you thought it might be safe....
-- 
        John Higdon         |   P. O. Box 7648   |   +1 408 723 1395
        john@zygot          | San Jose, CA 95150 |       M o o !

Date: Sat, 30 Nov 91 18:31 PST
From: john@zygot.ati.com (John Higdon)
Organization: Green Hills and Cows
Subject: Violated!

I feel violated! In today's mail, my new AT&T card showed up -- the
real one with the REAL AT&T number on it. After dutifully memorizing
it, I went to the supermarket where there is a known COCOT with an AOS
(ComSystems).

I dialed '0-714-972-0699' (a busy test number down south) and got the
ComSystems ka-bong. After dialing my AT&T card number, an operator came
on the line and asked what type of call this was. "Calling Card", I
replied. "What type of Calling Card?" "AT&T" "Card number please ...
just a moment ..." The ComSystems operator was gone for about a full 
minute. When he came back, he said, "Thank you for using ComSystems --
have a nice day."

Then I got my busy signal. Now, I can imagine that while he was gone
he was trying my card on a test number for verification. But my
question is: how can ComSystems bill a call made on an AT&T number?
How would it show up? Is AT&T STILL sharing its database with the
slime?


        John Higdon         |   P. O. Box 7648   |   +1 408 723 1395
    john@zygot.ati.com      | San Jose, CA 95150 |       M o o !