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 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 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 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 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 Reply-To: David Devereaux-Weber 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 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 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 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 Reply-To: Paul Robinson 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 ******************************