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