
From telecom-request@delta.eecs.nwu.edu  Mon Sep 25 19:48:53 1995
by
1995
19:48:53 -0400
telecomlist-outbound; Mon, 25 Sep 1995 13:34:29 -0500
1995
13:34:26 -0500
To: telecom@eecs.nwu.edu


TELECOM Digest     Mon, 25 Sep 95 13:34:00 CDT    Volume 15 : Issue 403

Inside This Issue:                           Editor: Patrick A. Townson

    Cell One/NY Fraud Control Problems, More ... (Doug Reuben)
    No Service in Boston for CO/Rhode Island Customers (Doug Reuben)
    Captive Tele-Consumers (Jim Cantrell)
    Book Review: How To Access The Federal Government on Internet (Rob 
Slade) 
    UUNet Drops Access Via Compuserve, Leaves UUCP Customers Hanging (A
Boritz)
    Need Assistance Doing ISP Traffic Analysis (Martin J. Slover)

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:

                 * telecom-request@eecs.nwu.edu *

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:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 500-677-1616
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

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 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.

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



Recently, Cell One/NY (00025) announced mandatory use of the *560/*56 
Fraud Protection Feature. 

This feature forces customers to enter *560+PIN (4 digits) after their 
phone has been off for approximately 25 minutes. By doing so, it is felt 
that cloning will be reduced as it will be harder to place calls if the 
cloner does not know the PIN. (Solution: KEEP THE PHONE ON! - If a 
cloner 
keeps the phone on, then the fraud protection feature is defeated, as it 
never 'kicks in'). 

Despite this obvious flaw, the McCaw/Cell One (now using the silly and
hard-to-say "AT&T Wireless" name just so AT&T can be like Sprint) fraud
protection feature is vastly superior to the "B" side fraud protection
implementation in the Northeast, as on the B side: 

(a) a PIN code is required for EVERY call,

(b) if a number is busy you can NOT hit "END" and then "SEND" to re-
dial,
    since entering the PIN code erases the destination number,

(c) you waste extra airtime (which NYNEX actually CHARGED for a few 
months
    ago ... they say they have corrected this now ...),

(d) and you can't use a cellular modem or a Cellular -> RJ-11 adaptor

(HINT: To get them to remove the PIN feature from SNET, NYNEX, or BAMS 
(B) accounts, just call and firmly state that you signed up so that you 
could use your cellular modem, and that you expect to be able to do so, 
BOTH in your home system and while roaming. Don't let them tell you any 
nonsense about calling your modem manufacturer, just demand (calmly :) ) 
that it be removed. They will comply, and if they don't, tell them you 
will immediately cancel your service contract with them and NOT pay a 
dime in penalty fees, and that you want your monthly "in advance" 
service 
fee returned to you.)

Anyhow, when Cell One/NY initially offered the Fraud Protection feature 
to its customers last year, I reported a series of problems with the 
feature that made it impractical. For example, if you roamed out of NY 
with the feature "on" (ie, outgoing calls were denied), you would not be 
able to change call-forwarding on turn call-delivery on or off from 
visited (roaming) markets, such as Connecticut's and (then) ComCast's 
EMX-based systems. In other Ericsson based markets, such as Albany and 
Cantel's eastern Canadian systems, calls were blocked at all times, and 
in many cases incoming calls would also fail. In all, the system was so 
unreliable and useless that I had them take it off my phone. 

It seems that they've made a number of improvements, and that it is now 
a 
generally useful and unobtrusive system, except for one problem: 

In the US Cellular/Poughkeepsie (00503) system, (and perhaps in others), 
if the fraud protection feature is active (ie, no outgoing calls 
allowed), if the phone is registered (turned on) within the system, and 
a 
CO/NY roamer receives a call, it will be sent up to Poughkeepsie and 
simply fail. Not message, no fast-busy, just dead air. 

This is NOT the way the Fraud PF should work -- incoming calls are 
ALWAYS 
allowed (unless Do Not Disturb is active, but you should be able to turn 
Do Not Disturb *350/*35 on and off EVEN with Fraud Protection "on"). 
Currently, when in the US Cell 00503 system, a CO/NY customer can not 
receive calls with the feature on, and has no way to know to turn the 
feature on unless he/she tries to place a call and discovers that 
service 
is denied. 

I've called CO/NY about this, and they are looking into the problem, but 
so far, nothing has been resolved. I'd like to hear from other 
McCaw/AT&T 
customers who have had similar experiences in the instant as well as 
other markets, especially Canada. 

Other problems with CO/NY:

1. Most other markets do not have recordings to support the fraud 
protection feature. So when a CO/NY customer roams into a new market, 
and 
discovers that he/she can not place any calls (or receive them as in the 
case with Poughkeepsie), the recording the roamer receives is of no 
help, 
and the roamer has no idea why the calls keep failing. 

For example, in Poughkeepsie, there is no recording -- the cell site 
simply hangs up on the caller about 3 seconds after the channel is 
opened 
(like Cantel used to). In ComCast (NJ/DE/Philly), the recording states 
"If you are having trouble with your service feature, please call 611". 
611, unfortunately, goes to a roaming operator when the Fraud Protection 
Feature is active! :(

2. Cell One/NY recently, and quite foolishly, commenced mandatory 1+ 
dialing for most calls, even in many cases for calls within their own 
service area. This has been explained to me as a "requirement" since 
AT&T 
now owns them, but unless this "requirement" is specific to AT&T-owned 
properties under the MFJ, I am not aware of any such MFJ, DOJ or other 
requirement on the Bell-owned carriers. Indeed, most of them do NOT 
require 1+ dialing in their markets, ever for roamers. 

The 1+ requirement wastes airtime, control channel overhead, and 
generally inconveniences customers no end. It is also not the slightest 
bit necessary (unless the Ericsson switch, which in order to provide for 
equal access, needs to have 1+ dialing. This still does not explain the 
requirement that roamers dial 1+ for "local" calls. If it is an Ericsson 
requirement, I think Ericsson may want to consider a software release to 
correct this).

My cellphone is programmed with mainly 10-digit numbers. In some 
markets, 
10-digit dialing is REQUIRED, and 11 digit will fail. I really don't 
want 
to have TWO sets of numbers in memory, one for CO/NY, the rest for 
eslewhere.

This is a really frustrating requirement, and unless this is some scheme 
by AT&T to get people used to 1+ local dialing because they are dreaming 
of local equal access some day :), I'd suggest that CO/NY just get rid 
of 
it. (Note that NYNEX does not require it ...)

3. As a result on the 1+ requirement, you need to dial *71+1+AC+# to 
forward a call. However, in most other markets, you can hit *71+AC+# (no 
extra "1"), and the call will be processed and sent to NY's switch. 

What happens? When a caller calls your CO/NY number that has been 
forwarded, they get a recording "Your call can not be completed as 
dialed". You need to dial "*71-1-AC+#" from roaming markets as well to 
forward your calls properly. Another pain in the neck with is IMHO 
unecessary, and will lead to customer confusion. There are so few 
customers who use their features currently, in part because of the 
complications involved in roaming and previous frustrating experiences; 
this new problem makes it even less likely that they will ever want to 
use their features. 

4. CO/NY customers who forwarded their calls in CT (in the Metro Mobile
system, not in CO/NY's "country" system in Litchfield, CT, which they 
got
after the local system failed to attract customers. Of course, they were
charging 60 cents per minute for HOME customers in an area of CT 
populated
mainly by cows...) were NOT able to unforward them, even though Metro 
Mobile reported the confirmation tones upon the roamer's request to 
unforward the call. This led the customer to think that he/she could 
receive calls, when in fact, they were still being forwarded. 

After contacting CO/NY, they seem to have swiftly addressed the issue, 
however, I'd be interested to hear if RI roamers in the ex-Metro Mobile 
system or Western Mass "A" side roamers continue to experience these 
problems. (Or am I the only one who drives there? :) )

5. AT&T 500 service is STILL blocked in CO/NY's system, this after two 
weeks notification of the problem and a nice letter from AT&T saying 
"You 
may now use 0-500 dialing from your carphone..." Is it just me, or have 
things gotten a bit worse with AT&T 500 access AFTER AT&T managed to 
take 
over?

Hmmm ... that should about do it for now. I'll post followups as 
progress 
is made.


Regards,

      Doug Reuben  *  dreuben@interpage.net   *  +1 (203) 499 - 5221
Interpage Network Services -- http://www.interpage.net, telnet 
interpage.net
E-Mail Alpha/Numeric Local/Nationwide Paging, Info., and E-Mail <-> Fax 
Svcs 

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



Recently, Bell Atlantic Metro Mobile's Rhode Island division was sold to 
Southern New England Telephone, the local Bell company in Connecticut, 
and 
the "B" side carrier in CT and (now) all of Western Mass.

Around the same time, Southwestern Bell-Cell One/Boston ridded itself of
its Motorola EMX switches (except for their "partnership"/dually-owned
system in New Hampshire [01485] with Atlantic Cellular-Cell One/VT
[00313], which is still served by their EMX), and after a *very* messy 
and
unprofessional transition to an AT&T Autoplex switch which went on for a
month or so, has managed to get back to a more or less reliable system. 

However, something which no one seemed to notice was that a good deal
of Metro Mobile (errr ... sorry ... SNET/RI) customers were not able
to place or receive ANY calls in the Boston 00007 system. By this, I
mean no 611, no 911, no 0+, nothing! Each time a call was placed, the
caller would get an EQUIPMENT-generated "fast-busy" (ie, the signal
your cellphone makes, NOT the switch). When calling to a RI customer
in the Boston system, calls would simply be treated in RI and were
never sent to Boston.

One of my friends who has been a long time MM/RI customer called me
one day in early July to ask me if something was going on. After
checking it out with him, and confirming his results, I told him to
call MM/RI, and have them fix the problem. So he called, and called,
and called, and each time was met by a very polite representative, but
no one ever called back, and nothing was done.

Moreover, a number of MM/RI customers who we associate with and who 
travel to Boston frequently (the Boston system starts 10 miles north of 
RI, so there is a lot of cross-traffic) also reported a similar problem, 
and after speaking to some of them, learned that they also received no 
followup to their inquiries and that nothing had been done -- no one was 
able to place or receive calls in the Boston system.

At this point, since we pay for an account with MM/RI for a consultant 
who travels to Boston a lot, I decided to get involved, and press them 
to 
correct the situation. I initially spoke with Todd Palmer (who seems to 
have a somewhat authoritative position there), who handed me off to Mary 
Rigiornio in their Warwick, RI office. Both were friendly and expressed 
an earnest desire to correct the problem. When I inquired as to why this 
has been going on for *three* months an nothing had been done prior to 
my 
calls, they both had no answer, however.

In any event, this was three weeks ago. I've called both of them a 
number
of times recently, and neither has returned my calls. The situation is
still the same -- many, if not all, RI and Southeastern Mass "A" (00119)
customers can not place calls in the Boston system. I know from my own
trials that 401-523 and 508-997 do not work at all, and from what I can
tell from other customers' reports who have service on other RI/SE MA
cellular echanges, their success with placing/receiving calls in Boston
has not been any better. 

At this point, I've more or less given up with the people in MM(CO)/RI, 
and have already made contact with SNET Mobile in New Haven to see if 
someone from there can get things moving. 

If there are any MM/RI customers who are reading this who have 
experienced similar problems in Boston, could you please drop me a short 
note and just let me know the area code and prefix of your phone? (I 
don't need the whole number). If you are reading this from some Web 
Newsreader, go to "http://www.interpage.net", select to leave mail, and 
send it with the subject "RI Cell" and I will receive it.

I'll post updates as the situation warrants ...


      Doug Reuben  *  dreuben@interpage.net   *  +1 (203) 499 - 5221
Interpage Network Services -- http://www.interpage.net, telnet 
interpage.net
E-Mail Alpha/Numeric Local/Nationwide Paging, Info., and E-Mail <-> Fax 
Svcs 

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



jerald@wrs.com (Jerald Pendleton) wrote:

> I recently recieved a bill I incurred during a recent vacation.  I
> made several phone calls from my motel room to numbers within the
> state of California.  They charged me $9.13 for a four minute call
> (apparently four minutes is the minimum) ... The phone was blocked...

I've had my own experiences with these types of scams -- perhaps not 
scams
technically, but morally.

I have paid innumerable charges from operator assist collect call
outfits that survive by taking advantage of the unwary traveler.  I've
also received innumerable solicitations from these same companies
wanting me to sign up pay phones on their service in order to split
the $2 or $3 per minute charges.

My response when I turn down these opportunities to "TURN THAT PAY
PHONE IN TO A PROFIT CENTER!" is that we provide pay phones for the
convience of our customer, associates, and employees, all of whom we
value to dearly to gouge for nickle and dimes.

It is time we initiate legislative action to provide some protection
for the consumer.  The situation as I see it:

  1. The companies do not provide additional value in exchange for
higher price.  They are not investing in the installation of more
phones but rely on switching these services from other, usually
cheaper, services and provide only what was already available but at
an increased rate.

  2. They prey on an almost captive consumer.  The market base for
these services are primarily people in transit -- customers at motels,
truckstops, hospitals, etc. -- who may not have an understanding of the
alternatives or the costs they are incurring. In many motels, use of
an alternative service is made as difficult as possible.

  3. A sound contract requires a knowledgable agreement by both
parties of the terms.  Although callers undoubtedly realize that they
or the called party will be charged for the call, many are unaware
that the charge may be double or triple the lowest rates available.
Those who accept collect calls made via these companies receive no
warning, sometimes the identity of the service provider AFTER the call
is accepted.

We can't ban these companies from providing service at these
preposterous rates or prohibit hotels and motels from gouging their
customers, however, it is fitting and proper that we require, through
legislative actions at the state and federal levels, that these
services provide the information necessary for the consumer to make a
knowledgable decision.

Every hotel and motel should have rates and alternate carrier
instructions readily available to every phone user; every collect call
should have the rates available or announced to the caller, the rates
and identity of the service provider announced to the recipient of the
call.

The companies that provide these services will complain about the cost
of implementation, but what the heck, were already paying for it.

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

Internet"


BKHAFGOI.RVW   950712
 
"How to Access the Federal Government on the Internet", Bruce Maxwell, 
1995,
1-
56802-034-1, U$22.95
%A   Bruce Maxwell bmaxwell@netcom.com
%C   1414 22nd Street N.W., Wasington, DC   20037
%D   1995
%G   1-56802-034-1
%I   Congressional Quarterly Inc.
%O   U$22.95 +1-800-638-1710 +1-202-822-1475 fax +1-202-887-6706
%O   202-822-1423 fax 202-822-6583 eashley@cqalert.com
%P   402
%S   Washington Online


                                                    

%T   "How to Access the Federal Government on the Internet"
 
For those interested in (the U.S.) government, and access to its
information, Maxwell has provided a very useful compendium of
addresses.  As he admits, this is not an exhaustive list to U.S.
federal government systems available through the Internet, but it
definitely gives a good, broad starting field.  University and other
sites with a specialized interest in the government are listed,
although strictly political organizations are rare.  For example, the
"Queer Resources Directory" is included, but the Electronic Frontier
Foundation is not.
 
The reader is expected to be reasonably familiar with the Internet
use: the information given in the introduction is too brief to be
helpful to a neophyte.  The listings themselves, however, give clear
"vital statistics" on access methods, and a detailed and useful
write-up for each site.
 
All of that would be extremely valuable for those interested in
government and access to information, but since the feds have fingers
in just about every pie, there is much more.  The various departments
provide information on agriculture, business, computers, demographics,
education, energy, environment, foreign affairs, medicine, history,
employment, law, technology, and transportation.  Government sites
often provide the most informative content to be found in the net.
Maxwell has added to this with a very useful index: I didn't really
expect to find anything under "Viruses, computer" but was pleasantly
surprised to note a pointer to the NIST Computer Security Archive
(http://csrc.ncsl.nist.gov).
 
For the avid U.S. government watcher, an essential.  For the serious
Internet information gatherer, regardless of nationality, a very
useful resource.

 
copyright Robert M. Slade, 1995   BKHAFGOI.RVW   950712. Distribution
permitted in TELECOM Digest and associated publications. Rob Slade's
book reviews are a regular feature in the Digest.

ROBERTS@decus.ca    rslade@cln.etc.bc.ca    
rslade@freenet.vancouver.bc.ca 

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

Hanging


UUNet announced to their customers last week that they were
discontinuing access via Compuserve's packet-switched network by
10/1/95, and phasing in a new V.34 rotary (with much fewer POP's).
The announcement, written 9/15/95, left their customers a little more
than two weeks to change their access arrangements, or find service
elsewhere.  Also in their announcement to UUNet customers, UUNet
staffer Michael Byman announced that they were phasing out uucp
service on the older rotaries.

The only problem, though, is that both uucp and ip customers are
experiencing some severe connect problems through the new V.34 rotary,
which appear to be running Ascend Pipeline Terminal Servers.  UUNet
doesn't appear to be in a hurry to respond to connect problems with
this new (and more expensive) access arrangement, or at least not for
uucp customers (no doubt Microsoft Net customers will be treated a lot
better).  Now that UUNet has expanding their customer base, and will
be publicly traded, one would think they would have the resources to
develop a competent technical support group.  Or perhaps this was the
area within which UUNet stated they had to hire additional qualified
personnel (in their 5/25/95 perspectus).  Time will tell if they
really mean business, or if this is just one very rude way of getting
rid of one class of customer that they may see as less profitable.

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



I am hoping that this gets out in time but I need some assistance in
doing a report on traffic analysis in regards to setting up an ISP.
Specifically I need comments on what grade of service would I
specifically want?  What demands on the systems cause the most
problems with traffic flow? If anyone can give me some info please
email me at indigo@crl.com.


Thanks...

Max Slover     Indigo@crl.com 

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

End of TELECOM Digest V15 #403
******************************

                                                
