home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
DP Tool Club 15
/
CD_ASCQ_15_070894.iso
/
vrac
/
tc14_246.zip
/
TC14-246.TXT
< prev
Wrap
Text File
|
1994-06-07
|
29KB
|
654 lines
TELECOM Digest Tue, 24 May 94 00:43:00 CDT Volume 14 : Issue 246
Inside This Issue: Editor: Patrick A. Townson
Book Review: "Getting Online" by Wood (Rob Slade)
Followup: Connect a Card Reader to a Cell Phone? (Andrew C. Green)
Local Call Billing in the UK (Richard Cox)
CNID *Can* be Spoofed! (Andrew Robson)
Documents for AT&T Model 1539? (Bob Keller)
Urgently Request For Help With Research (Ali Tianero)
PCBX Systems (Paul Barratt)
Speech Recognition "Word Spotting" (p.bflower@uts.edu.au)
900 mhz Cordless Phone; Any Information? (Jason Chou)
Re: 800 Number Billback (Charles Chambers)
Re: Information Wanted on Large Digital Data Exchange (D. Devereaux-Weber)
Re: Cellular Phone Timers (Shawn Gordhamer)
Re: NPA Optional in 818 - it Works! (sameer@atlas.com)
Re: New (Lame) Directory Assistance From GTE Mobilnet (Marty Brenneis)
Re: Wanted: Hand-Held Challenge/Response Units (Paul Robinson)
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 GEnie.
It is also gatewayed to Usenet where it appears as the moderated
newsgroup 'comp.dcom.telecom'.
Subscriptions are available at no charge 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: 708-329-0571
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. *
*************************************************************************
Additionally, 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.
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.
----------------------------------------------------------------------
Date: Mon, 23 May 1994 15:30:37 MDT
From: Rob Slade <roberts@decus.ca>
Subject: Book Review: "Getting Online" by Wood
BKGTONLN.RVW 940315
John Wiley & Sons, Inc.
22 Worchester Road
Rexdale, Ontario M9W 9Z9
800-263-1590
or
605 Third Avenue
New York, NY 10158-0012 USA
800-263-1590 212-850-6630
Fax: 212-850-6799
jdemarra@wiley.com aponnamm@jwiley.com
"Get On-Line!", Wood, 1993, 0-471-58926-8, U$24.95
Most computer users do not yet have a modem, or don't use it on a
regular basis. Those who do get a modem need a fair amount of help
from a knowledgeable friend. It would be helpful to have a book which
covers all of the traps of buying a modem, what you need, how to hook
it up, how to set up the configuration and software, and how to
connect to some outside source. The basics of how to deal with email,
file transfers, and how to use material with other programs. This is
what Wood tried to do.
He only partially succeeds. First, you had better have a PC and
either Procomm Plus, Crosstalk XVI, Smartcom EZ or Windows Terminal.
The descriptions of functions are written strictly for field
independent people: those who don't care what is going on, they just
want to know what key to press. As long as nothing goes wrong with
the communications session, this is fine. Online devotees will know
that the chances of nothing going wrong are extremely slim.
Wood's material is quite dated. It is very odd that any book written
in the past two years and purporting to advise on modem purchase does
not mention 14400 bps modems. Also odd is the recommendation to buy
MNP 3 or 4 modems: I haven't personally seen one with less than MNP 5
in more than four years. I also haven't seen an acoustic coupler
modem available for quite some time.
The content is also quite sparse in places. While I can appreciate
the desire to write for the non-technical user, the truth is that
computer communications is still a field requiring some background to
set up. Wood mentions the possible problems with COM ports and IRQ
levels -- but only mentions them. There simply isn't enough
information here even to start to diagnose or rectify an interrupt
conflict problem. The book even suggests that COM ports on computers
are so labelled, an unlikely eventuality. This style follows through
to the communications parameter settings. Wood does give good
suggestions for default settings, but no means of determining
problems.
The book does contain a smattering of everything. There is a bit on
portable communications, online services of various types, netiquette,
and so forth. Since these are not really the main thrust of the book,
one does not expect extensive discussion, but it seems a bit terse to
dismiss the Internet in less than two pages as an "echo network" and
"more chaotic than any of the BBS echo networks." (There are quite a
number of errors in the short piece on the Internet. And I should
also mention a section on viral programs which lists seven antiviral
vendors -- four of whom are McAfee agents.)
For novices, this does give a good starting guide, but only that. You
will still need your knowledgeable friend.
copyright Robert M. Slade, 1994 BKGTONLN.RVW 940315. Distribution
permitted in TELECOM Digest and associated newsgroups/mailing lists.
Vancouver ROBERTS@decus.ca
Institute for Robert_Slade@sfu.ca
Research into rslade@cue.bc.ca
User p1@CyberStore.ca
Security Canada V7K 2G6
------------------------------
Date: Mon, 23 May 1994 16:36:09 CDT
From: Andrew C. Green <ACG@dlogics.com>
Subject: Followup: Connect a Card Reader to a Cell Phone?
You may remember that about a month ago, I asked for help in locating
equipment that would connect a credit card authorization reader to a
cellular phone, for my father's use at a concert. His organization,
Symphony II, the orchestra of the Chicago Lyric Opera, was holding a
"silent auction" fund-raiser, and needed a way to get credit card sale
authorizations at a location where no POTS line was available.
Well, TELECOM Digest readers sent numerous recommendations and offers
of assistance, and thanks are due to Macy M. Hallock, Jr., Alan
Larson, Donald L. Wegeng, Henrik Rasmussen, Merrell Sheehan and Paul
A. Lee for their information, and of course PAT for operating TELECOM
Digest in the first place. (I apologize if I've overlooked anyone.)
As it turned out, Motorola stepped in to help. Following Paul Lee's
suggestion, my father contacted Bill Cochran of Motorola, who
forwarded the question on to his associate Sonya Borre' (any
misspellings are mine). She showed up bang on time at 9:00 a.m. the
Monday before the concert at Symphony II offices for a demonstration
of the gadgetry required to connect the cell phone to the reader. All
went well, and Motorola graciously loaned the necessary equipment at
no charge. The concert was held on Sunday afternoon, May 22nd, at
Pick-Staiger Concert Hall at Northwestern University in Evanston, IL,
and all the credit-card authorizations during the auction went through
with no problems.
So, readers of TELECOM Digest have been instrumental in solving the
problem for us. We thought you'd like to know.
Regards,
Andrew C. Green Datalogics, Inc. Internet: acg@dlogics.com
441 W. Huron Chicago, IL 60610-3498
------------------------------
Date: Mon, 23 May 1994 16:02:59 -0700
From: richard@mandarin.com
Subject: Local Call Billing in the UK
RANDY@MPA15AB.mv-oc.Unisys.COM said:
>> These were local toll calls from the East End to the West End, which I
>> assume are expensive calls.
{Chuckle} It is claimed that local phone calls in the UK are more
expensive than in most countries ... one UK pound buys about 38
minutes of call (before UK tax). The fact that this call was made
from the East End to the West End (about six miles in distance) is
completely immaterial -- the charge would have been exactly the *same*
as the charge for a call to next door.
Calls on the BT network (the dominant provider both as LEC and IXC in
the UK) are currently charged in "units" and on most COs, calls of
more than nine units can be itemised irrespective of the distance/des-
tination of the call. The duration of a unit depends on the distance
and type of call, as well as the time the call is made. The price of
a unit depends on the calling plan of the individual customer, which
is known in BT-speak as a "customer option".
There are plans to abolish the unit-charging over the next few years.
Before STD ("DDD") was introduced here, local calls were charged as
one, two, three or four unit fee calls, depending on distance: but the
calls were untimed.
>> Did the U.K. implement itemized local billing?
Local billing in the UK has been part of the national ("STD") billing
scheme ever since STD was introduced in the various areas (from 1958
onwards). The option for itemised billing was more recently
introduced, but treats local & long-distance in identical ways. In
fact the trend here is for the cost of local calls to increase, and
the cost of long-distance to drop ... for just the same reasons that
charges for intra-LATA long distance in the USA, are so much higher
than for inter-LATA long distance. And the costs involved are mostly
for the switching, as bit-haulage is getting cheaper all the time!
Richard D G Cox
Mandarin Technology, P.O. Box 111, Penarth, South Glamorgan, Wales: CF64 3YG
Voice: 0956 700111 Fax: 0956 700110 VoiceMail: 0941 151515 Pager 0941 115555
E-mail address: richard@mandarin.com - PGP2.3 public key available on request
------------------------------
From: uswnvg!arobson@uunet.UU.NET (Andrew Robson)
Subject: CNID *Can* be Spoofed!
Date: Mon, 23 May 1994 18:32:22 PDT
It would appear that Calling Number Identification can be spoofed, at
least for some applications.
My most valuable, though low key, use of CNID was as an aid to keeping
track of my teenage children. If they are supposed to be at some partic-
ular location (e.g. spending the night at a friend's house), their
knowledge of the service assists them in resisting the temptation to
lie about their location when checking in. This weekend we inadvertently
discovered a weakness in the system.
We received a call for one of the children from a friend (call her K)
which appeared to come from a different friend's (call her A) home.
Since I had a message for A, I asked if she could be put on the line
since K was calling from A's house. K denied vehemently being at A's
house so the call ended poorly.
I later found out what apparently had happened. A had been talking to
K and they decided to add my child to the conversation. So A placed a
3-way call to my house, added K, but was then called away from the
phone. K was there when I answered, and was indeed at home, not at
A's house.
So CNID can be spoofed if there is a willing collaborator at the
desired apparent origin of the call. Since my kids participated in
figuring out what happened, they know how it is done. I now have only
a little more assurance of their location than my parents did of mine. :-)
Andy
[TELECOM Digest Editor's Note: But it isn't the CNID which is being, as
you put it, 'spoofed'. Telco *is* reporting to you where the call you
received originated at. The fact that another party to the three-way
call was not identified on the display can hardly be termed a weakness.
You say that 'K' vehemently denied being at the home of 'A'; while she
was telling the truth she was doing so out of context obviously, and
as the conversation continued I am surprised that she did not mention
the fact that the call was three-wayed through 'A'. In a way, it seems
odd that 'A' was called away from the phone just as the three-way
connection was established and was unable (or chose not) to return to
the line for the duration of the call. Don't forget, you are also free
to place a call back to the number shown on the display; either your call
back to the number shown will result in a straight forward connection to
your daughter or it will result in clicking on the line while the call
is being forwarded or your being placed on hold while another three-way
call is set up.
Most folks can tell by the sounds they hear as a call is being established
whether or not it is in fact being forwarded (listen for extra clicks
or the slightest delay not usually there, etc) and in the event the
call does go through as dialed a simple request 'do not put me on hold
while you call my child to the phone' would either result in your
child answering forthwith or the other end's inability to produce your
child (since you have forbade the use of hold they can't very well
flash and get another three-way connection up.) Still not perfect, I
realize, but with a callback from your end you've added the need for
more complicity on *their* end(s), and the risk that among them,
someone's parent is likely to answer the phone, or come on the line,
etc. In other words, you can add to the obstacle course and increase
the likelyhood one or more of them will be caught in a lie. PAT]
------------------------------
Date: Mon, 23 May 1994 22:06:56 EDT
From: Bob Keller <rjk@telcomlaw.com>
Subject: Documents for AT&T Model 1539?
Does anyone have the documentation (manual, instructions, etc.) for an
AT&T Model 1539? This is a single line telephone with a built-in
digital (non-tape) remote answering system. I picked one up (or most
of one anyway -- it was missing a few cables, mounting brackets, etc.)
"as is" out of a "bargain bin" at a local office supply store. If
anyone has whatever booklet explains the ins and outs of this thing,
I'll gladly reimburse any reasonable expense incurred in copying and
mailing/faxing it to me. Thanks!
Bob Keller <KY3R> Robert J. Keller, P.C. Tel +1 301 229 5208
rjk@telcomlaw.com Federal Telecommunications Law Fax +1 301 229 6875
finger me for daily FCC info + see ftp.clark.net:/pub/rjk/ for other files
------------------------------
Date: Tue, 24 May 94 09:57:59 JST
From: ali@ntep.tmg.nec.co.jp (Ali Tianero)
Subject: Urgent Request For Help With Research
Hello, Patrick!
I already wrote to the telecom listserv and asked for the index.
I couldn't find any information on cross connect equipments. I decided
to mail you personally in the hope that you can help me with my problem.
We are studying XC equipment classes and attributes for an incoming
project but we lack the needed data for a thorough study. In my
opinion, it would help us with our project if we get to know more
about the actual equipment so that the XC classes and attributes we
are dealing with would become more concrete.
Once again, thanks for any help you can extend.
Azaleah S. Tianero | email : ali@ntep.tmg.nec.co.jp
NEC Technologies Phils.,Inc. | tel(voice) : +63 (32) 400-451
MEPZ, Lapu-Lapu City | tel(fax) : +63 (32) 400-457
6015 Cebu, PHILIPPINES | telnet(voice) : 8-0063-21-1653
| telnet(fax) : 8-0063-21-1607
[TELECOM Digest Editor's Note: This party wrote essentially the same
note originally to the Digest mailbox, and I did nothing with it. He
then today wrote me at my personal maibox; I still don't really know
how to answer him. If anyone wants to take a crack at it, please do
so, writing Mr. Tianero personally. PAT]
------------------------------
From: paulb@iconz.co.nz (Paul Barratt)
Subject: PCBX Systems
Date: 24 May 1994 01:26:49 GMT
Organization: Public Access Internet, Auckland New Zealand
I had a look today at a system from PCBX, a small business PBX based
on 386 / 486 DOS platform. Does anybody have any user experience with
this technology? Looks pretty tidy, only not quite %100 for NZ
telephony network.
Thanks,
paulb@iconz.co.nz
------------------------------
From: pbflower@uts.EDU.AU (-s89432566-p.bflower-ele-500-)
Subject: Speech Recognition "Word Spotting"
Date: 23 May 1994 23:43:02 GMT
Organization: University of Technology, Sydney
I'm looking for info on Word Spotting. Any info on developing a HMM to
do this would be much appreciated. Please mail information or names of
books, papers etc. that will do this.
------------------------------
From: jay@kaiwan.com (Jason Chou)
Subject: 900 mhz Cordless Phone; Any Information?
Date: 20 May 1994 11:00:03 -0700
Organization: KAIWAN Internet, CA
Is there any information about 900 mhz cordless phones? Has anyone
heard of Micro 900 MHz by Bel-Tronics Limited? Any good? Thanks!
Jason Chou | internet:jay@kaiwan.com | compuserve:70254,3706
------------------------------
From: chambers@uh.edu (Charles Chambers)
Subject: Re: 800 Number Billback
Date: Fri, 20 May 1994 15:59:08 -0500
Organization: University of Houston
Based on the way these LD companies are handling charge back billing
based on your ANI, what would the problem with having your ANI blocks
from all LD companies (thus they can not bill back to it). I know that
this currently can not be done, but rather, if it could be done, what
would be the problems?
Charles Chambers University of Houston
Telecommunications Department Manager of Network Services
[TELECOM Digest Editor's Note: The problem would be two-fold. First
off, the rules currently say that local telcos may not withhold
name and address information from long distance carriers -- even if
the number is otherwise non-published -- for billing purposes. Local
telcos are not in a position to evaluate the content of the connection
given or the cost for same (except for stuff like billing errors, etc).
So if the rule was changed where you the subscriber were allowed to
refuse any and all information to the long distance carriers, then you
would wind up with no long distance service at all; after all, what
carrier would want to handle your calls on the assumption that you might
or might not decide reveal yourself and pay for it? You can get basically
the same results now if you really want them: by not choosing any long
distance carrier (or choosing 'none' if applicable) your phone will be
effectively restricted from dialing long distance calls. Dialing 1 + 10
digits here (except for 700,800,900 calls) with no carrier default on
your line causes the call to go to an intercept (cannot be completed as
dialed). That still allows subscribers to deliberatly force a call out
using 10xxx + 1 + 10 digits, but it takes a conscious decision on the
subscriber's part; he is hardly in a position later to demand that the
carrier not bill him or collect on the charges. Another more call-proof
option available to subscribers -- at least here in Illinois Bell terr-
itory -- is to have the Business Office completely toll-restrict your
line. It can be set up in the central office with no overrides possible
at all. With complete toll-restriction, even dialing through the operator
won't work since she won't be able to complete the call for you either.
Double zero (for the long distance operator) will go to an intercept.
You *will* be able to place collect, credit card or third-party billing
calls however ... just no direct dial or operator assisted paid calls. PAT]
------------------------------
Date: Mon, 23 May 94 14:02:27 CST
From: David Devereaux-Weber <weberdd@clover.macc.wisc.edu>
Reply-To: David Devereaux-Weber <weberdd@macc.wisc.edu>
Subject: Re: Information Wanted on Large Digital Data Exchange
We have a set of rack mounted modems from:
Multitech Systems
2205 Wooddale Dr.
Mounds View, MN 55112
(800) 328-9717 (612) 785-3500
We have about 400 on-line now, with plans to expand to 1000.
David Devereaux-Weber, P.E. weberdd@macc.wisc.edu (Internet)
The University of Wisconsin - Madison (608)262-3584 (voice)
Division of Information Technology (608)262-4679 (FAX)
Network Engineering
------------------------------
From: shawnlg@netcom.com (Shawn Gordhamer)
Subject: Re: Cellular Phone Timers
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Mon, 23 May 1994 23:47:16 GMT
Tony Harminc <EL406045@BROWNVM.brown.edu> writes:
>the phone has to be told by the network when charging starts and ends
> -- a supervision signal, if you will.
One big problem is that just knowing when charging starts and ends
won't be enough. There would also need to be a "charge cancel"
signal. When you dial someone, the charge starts immediately, while
the other phone is ringing (yes, you are charged ring time, at least
at Cellular One). But, if you hang up before they answer, the charge
is canceled. Therefore, there needs to be three signals to your phone:
- charge start pending
- chargable call
- charge end
I'd be happy if there was a way to subtract the last call from the
total time timer on my phone. I know if a charge is real or not, so
at the end of the call, I can hit the "undo charge" function, and get
an accurate total timer.
Shawn Gordhamer shawnlg@netcom.com Rochester, Minnesota USA
------------------------------
From: sameer@atlas.com
Subject: Re: NPA Optional in 818 - it Works!
Organization: Atlas Telecom Inc.
Date: Mon, 23 May 1994 22:21:51 GMT
In article <telecom14.231.12@eecs.nwu.edu> dasher@netcom.com (Anton
Sherwood) writes:
> I just tried it in 415. Hooray!
It works for the 503 Area Code as well in Portland, OR.
Sameer
------------------------------
Date: Mon, 23 May 1994 23:13:31 PDT
From: Marty Brenneis <droid@kerner.com>
Subject: Re: New (Lame) Directory Assistance From GTE Mobilnet (Bay Area)
On Tue, 17 May 1994 Henry Mensch wrote:
> Moral of the story: to use GTE's new gimmicky directory assistance dial 411
> or 555 1212 ... to get the real stuff dial *6543. Your mileage may vary,
> especially outside the Bay Area.
And TELECOM Digest Editor noted in response:
> [TELECOM Digest Editor's Note: Henry, a question and a comment: exactly
> what does this *6543 hook get you into? You said 'new, gimmicky directory
> assistance' which leads me to wonder, did not GTE offer directory assist-
> ance like any other telco until recently, i.e. 'new'?. Is the cellular
> division of the company offering a new service and intercepting calls to
> 411 or 555-1212 which formerly had gone to a full directory bureau and
> providing some limited sub-set of the directory?
We are not talking GTE landline service here, we are talking GTE
Mobilenet cellular service. They have decided to do their own DA
service with people who don't have a clue how to look up a number.
Once they look up the number for you they just connect you to it. Of
course they nick you a little more for this "service". You pay the
airtime while the person takes five times longer to find the wrong
number than a professional DA. The only good side is that they handle
DA for all of the GTE calling area, this way you can just dial 411 and
not worry about what the NPA is for your target party. Pac*Bell is the
local DA service from the landline side and they do an excellent job.
Perhaps the next time Pac*Bell lays off some DAs, GTE should hire
them.
Yo! You operating companies out there! I know that the DA centers have
been merging for many years. When I dial 411 in the 415 area the DA I
speak with really is taking calls for 415,510,707,408 and perhaps many
more. The ones in Sub California handle a bunch of NPAs. Why can't
they give the number that is outside the NPA that I dialed? It would
reduce traffic load.
Marty 'The Droid' Brenneis ...!uupsi!kerner!droid
Industrial Magician droid@kerner.com
(415)258-2105 ~~~ KAE7616 - 462.700 - 162.2 ~~~ KC6YYP
------------------------------
Date: Mon, 23 May 1994 15:18:35 EDT
From: Paul Robinson <PAUL@TDR.COM>
Reply-To: Paul Robinson <PAUL@TDR.COM>
Subject: Re: WANTED: Hand-Held Challenge/Response Units
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
> I'm looking for suppliers of hand-held challenge/response
> cipher key systems ...
> I envisage they'll work as follows:
> 1. User connects via public network to our system;
> 2. Our system lets them log in as normal, but they then
> are "challenged" with a long code.
> 3. The user must enter the code into the hand-held unit,
> which provides the "response" using RSA or similar.
> 4. The user then enters the "response", which is validated
> against the expected value. This may involve the use
> of a public/private key system also, for encryption
> of transmitted material.
> I'm very hopeful that units such as I've just described exist -- if no
> perhaps someone wants to make them? (e.g. based on HP-100LX).
You need nothing near this complicated or expensive. A simple, and
free system for doing the exact thing you have described, called
"skey" is already available. The user can either preprint the
one-time usage passwords or run a short program on his own PC to
compute them. Any time prior to running out of passwords he can
generate some more.
The following is from the documentation for the program:
Description of The S/KEY One-Time Password System
Neil M. Haller nmh@thumper.bellcore.com
Philip R. Karn karn@chicago.qualcomm.com
ABSTRACT
The S/KEY one-time password system provides authentication over
networks that are subject to eavesdropping/reply attacks. This system
has several advantages compared with other one-time or multi-use
authentication systems. The user's secret password never crosses the
network during login, or when executing other commands requiring
authentication such as the UNIX passwd or su commands. No secret
information is stored anywhere, including the host being protected,
and the underlying algorithm may be (and it fact, is) public
knowledge. The remote end of this system can run on any locally
available computer. The host end could be integrated into any
application requiring authentication.
--------------------------
Had people been using this for network logins, that "password grabber"
program that was circulating a few months back would have been useless
and all people would have gotten was a lot of used and worthless
passcodes that no longer work.
A person who has it on their system told me that:
Generating the keys is a painless process of running a command or
two and typing in a password; the program(s) then generate a certain
number of keys which can be printed out and carried in a person's
wallet. No extra hardware is required.
The files for this system can be obtained via anonymous ftp to
thumper.bellcore.com: /pub/skey
Paul Robinson - Paul@TDR.COM
------------------------------
End of TELECOM Digest V14 #246
******************************