Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!texbell!vector!telecom-gateway
From: pdg@chinet.chi.il.us (Paul Guthrie)
Newsgroups: comp.dcom.telecom
Subject: Re: Sprint Bashing Should Stop!
Message-ID: 
Date: 15 Aug 89 03:48:47 GMT
Sender: news@vector.Dallas.TX.US
Reply-To: Paul Guthrie 
Organization: The League of Crafty Hackers
Lines: 29
Approved: telecom-request@vector.dallas.tx.us
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@vector.dallas.tx.us
X-TELECOM-Digest: volume 9, issue 297, message 8 of 8

In article  rick@uunet.uu.net (Rick
Adams) writes:
>Sprint claims that they have call supervision equipment in all areas that
>offer equal access.
>Why the continuing Sprint bashing? They aren't nearly as half-assed as
>you seem determined to present them.

Perhaps because what Sprint claims in call supervision is not really call
supervision.  They use 'energy detect', a  half assed method of determining if
somebody really did answer on many of their small town connections.  Try
dealing with Sprint as a heavy usage subscriber.  If you compare the amount of
lines running to a particular small town vs say AT&T (no contest) or MCI,
Sprint is sadly lacking.  I had a case where I needed *lots* of lines running
to Myrtle Bay, and Sprint had something like 4, where MCI had 4 T-spans!!!
This was not some strange case, either, rather the norm.

In any case, the number of Sprint terminations with true supervision, is not
the same as the number of Sprint terminations which they claim have 'answer
supervision'.

Also, Sprint (at least in this area) continuously used to give me service
problems, including such things as 'modifying' their service to only give one
way talk path before answer supervision without notification (1-800s emulating
FGB service need this).  I did have many problems with MCI too, but all of the
'memorable' experiences seem to have been with Sprint.

--
Paul Guthrie
chinet!nsacray!paul