Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id NAA27001; Sun, 30 Mar 1997 13:35:21 -0500 (EST) Date: Sun, 30 Mar 1997 13:35:21 -0500 (EST) From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor) Message-Id: <199703301835.NAA27001@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V17 #79 TELECOM Digest Sun, 30 Mar 97 13:35:00 EST Volume 17 : Issue 79 Inside This Issue: Editor: Patrick A. Townson Re: 911 From Cellular Phone in Chicago (Tad Cook) Re: 911 From Cellular Phone in Chicago (Anthony Argyriou) Re: 911 From Cellular Phone in Chicago (morian@pobox.com) Re: Caller ID on Blocked Calls (Ken Levitt) Re: Problem with NPA 760 (CA) Test Numbers (John R. Levine) Re: Where to Find the XDSL Beta's and Active Installs (Chris Martin) Re: Slammed by American Business Alliance (J. DeBert) Re: Fast Busy Signal (J. DeBert) Re: ISP Offering Unlimited Access via 800/888 - How?? (Judith Oppenheimer) Re: Modem to Modem Flow Control (Sheldon Laws) Re: Does This Warning Really Make a Difference? (Robert A. Pierce) Re: Can Rev J Flash Rev K on BSP? (Jay R. Ashworth) 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: * ptownson@massis.lcs.mit.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: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-329-0571 Fax: 847-329-0572 ** Article submission address: ptownson@massis.lcs.mit.edu Our archives are located at hyperarchive.lcs.mit.edu. The URL is: http://hyperarchive.lcs.mit.edu/telecom-archives They can also be accessed using anonymous ftp: ftp hyperarchive.lcs.mit.edu/telecom-archives/archives (or use our mirror site: ftp ftp.epix.net/pub/telecom-archives) A third method is the Telecom Email Information Service: Send a note to tel-archives@massis.lcs.mit.edu to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * 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. * ************************************************************************* 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. ---------------------------------------------------------------------- Subject: Re: 911 From Cellular Phone in Chicago Date: Sat, 29 Mar 1997 22:17:28 PST From: tad@ssc.com (Tad Cook) PAT wrote: > Now telco is saying that with cell towers which are 'clearly within > the boundaries of a given community' (meaning it is unlikely anyone > picked up by that tower would not be somewhere in the community) could > easily pass information to the ground stations to interpret 911 in the > context of that local community. In other words, the tower which is > right in the center of downtown Skokie could be reasonably certain > that a 911 call received was from someone in Skokie; it is doubtful > someone three miles away in Evanston would have hit that tower. So > even though the tower sends its calls via a landline to (let us say) > Schaumburg, Illinois where Ameritech is located, it could tell the > switch at that point to use a Skokie FX (foreign exchange) line to > dial out to 911, getting the call back to the Skokie Police. The > police would get the cellular phone number and the general location of > the tower handling the call. To do this, some cellular systems are using the Proctor CellLink system. This is a box installed at each cellsite which grabs the ANI of each cellphone call to 911, and passes it over special circuits to the correct PSAP. The system can tell which cellular tower face the call came from, and route it through the 911 tandem to the correct PSAP. For more information on CellLink, contact Proctor & Associates of Redmond, WA via solutions@proctorinc.com or 206-881-7000. They also make a device for PBXs that routes 911 calls from behind the PBX over dedicated trunks to the PSAP or tandem, passing along a unique ANI for each extension, so that they can get an exact location for each extension. Without it they just get an ID for the PBX trunk that it was dialed on. Proctor calls this product PBX ANI. Tad Cook tad@ssc.com Seattle, WA ------------------------------ From: Jj34a@aol.com (Anthony Argyriou) Subject: Re: 911 From Cellular Phone in Chicago Date: Sun, 30 Mar 1997 08:20:25 GMT Organization: DNAI ( Direct Network Access ) Reply-To: Jj34a@aol.com On 25 Mar 1997 15:08:35 GMT, grumpy@en.com (Seymour Dupa) wrote: > You mean it's not available *now*? What happens when a user dials > 911? In Ameritech/Cleveland, calls are answered by PSAP (Public > safety Answering Point). >> [TELECOM Digest Editor's Note: Just a quick mention of an interesting >> development here in the Chicago area ... Ameritech says 911 service is >> going to be available to cellular phone users this month. PAT] > [TELECOM Digest Editor's Note: At the present time, star-999 will {snip} > How is this handled in other places, and how precisely is the caller's > location known to the police? PAT] In California, ALL cellular 911 calls go to the California Highway Patrol. If the call is about an emergency not on a state highway, the dispatcher routes it to the appropriate local police dispatcher. Interestingly enough, in a few places, this _is_ the CHP, as they provide local policing under contract in a few areas. Anthony Argyriou formerly Anthony042@aol.com ------------------------------ Date: Sun, 30 Mar 1997 07:37:35 -0800 From: Morian Subject: Re: 911 From Cellular Phone in Chicago > How is this handled in other places, and how precisely is the caller's > location known to the police? PAT] In our area, we have a 911 service that covers the whole "county". When you dial 911 you get a central 911 office run by the Greater Vancouver Regional District, who say "911, police, fire or abulance?" and would route you to the correct police/fire dept based on your answer (ambulance is dispatched from one office in the GVRD). When you call from your cell, your dialogue would be: 911 - "911, police, fire or ambulance" you - "police" 911 - "For what city please?" You would then be routed to the city police or RCMP responsable for that area. Morian -- morian@pobox.com Finger above address for PGP public key and commercial email policy. ------------------------------ Date: Sun, 30 Mar 1997 10:46:16 From: Ken Levitt Subject: Re: Caller ID on Blocked Calls >> I've searched everywhere I can think of and can't find any info >> on whether or not there exist caller-id units, or PC software >> that will display caller-id numbers even if they've been blocked >> with something like *67. Does anyone know where I can get this >> kind of hardware or software? > [TELECOM Digest Editor's Note: Dear X ... you seem like a person > who is unclear on the concept. There is no caller-id box or PC > software which will do what you want simply because you cannot > get something out of nothing. There is in fact a way for "X" to get what he/she wants. All it takes is some money. 1. Get an 800/888 number. 2. Route it to an unpublished local number. 3. Pay to have your 800/888 carrier deliver real time ANI as Caller ID. 4. Reject all private calls because they could not have come through the 800/888 number. [TELECOM Digest Editor's Note: Well alright, that is one work-around I had not thought about. But strictly speaking, it is ANI and not CID. The results are the same on the display box, but telco's rationale is since you are paying for the call you certainly get to know what it is you are paying for. I got a couple other ntoes from X this morning in which he said the people on the Privacy Digest mailing list were insisting that the caller id data was being sent all the way to the box and that it was up to the box to honor a flag which indicated 'privacy'. This is just not true. Telco sends data telling the box to display the private notation; it does *not* send the number with a flag telling the box not to display it. That would be lunacy, to expect the people with caller id boxes not to be hacking them to get around that situation. On that other mailing list, they are probably getting this confused with the situation you described where the data originates as ANI and is being forwarded. Everyone should be aware that *67 (or whatever variation on it is used in your community) **never** is honored in th case of a call to an 800/888 number. You may *not* prevent the recipient of a toll free call from seeing your number. PAT] ------------------------------ Date: Fri, 28 Mar 97 11:36 EST From: johnl@iecc.com (John R. Levine) Subject: Re: Problem with NPA 760 (CA) Test Numbers Organization: I.E.C.C., Trumansburg, N.Y. > [ calls to 760 test numbers work better with some IXCs than with others ] >> But when I use _AT&T_ to call the (Pac*Bell) test number 760-400-0760, I >> seem to be failing. I do _not_ get an _AT&T_ rejection recording, but a >> recorded male voice announcing that my call cannot be completed as >> dialed. It seems to be a Pac*Bell recording, as the recorded male voice >> seems to be the same voice announcing a successful test to 760-400-0760 >> when I dial it via carriers _other_ than AT&T. These days, that doesn't tell you who actually rejected the call. With SS#7, an intermediate carrier can send a message back to the originating switch asking that it go to a failure message of some sort. This is most obvious when you dial an international number that's busy and get a regular U.S. busy signal because that busy signal is generated here in the U.S. This is a good thing, it frees trunks from calls that can never complete. Pat sez: > You would think though these days with the rapid increase in area codes > it would be just as simple or more so for the local CO to just accept > whatever it was given and if it did not work out locally simply hand it > over to the long distance carrier and say, "here, you try to figure it > out ..." Local telcos would be happy to do that, but the IXCs won't let them. Trunks and switches are still expensive enough that they want to block a call that cannot complete as early as possible. I admit with the possibility of SS#7 bouncing the call back to the originating switch and freeing up the trunk in a second or so, this is a less compelling argument than it used to be. John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, http://iecc.com/johnl, "New witty saying coming soon." ------------------------------ From: Chris_Martin Subject: Re: Where to Find the XDSL Beta's and Active Installs Date: Fri, 28 Mar 1997 07:40:53 -0500 Organization: "NetEdge Systems" Tony Toews wrote: > There are some areas where I'd sure like to see faster things. But > then I live in a town of 4000 so I don't expect faster access than > 33.6 modem for many years to come. So I think I'll be getting a small > satellite dish soon. And how big is Glasgow, Kentucky? The Glasgow Electric Plant board has offered services like Home LAN (via their broadband network), cable TV, internet access, and telephone service. Oh, they offer electric service too;) This project started ten years ago, not ten years from now. It *can* be done in small towns ... Chris Martin martin@NetEdge.com http://www.netedge.com NetEdge Systems PHONE: (919) 991-9253 FAX: (919) 991-9160 P.O. Box 14993, Research Triangle Park, NC 27709-4993 ------------------------------ From: J. DeBert Subject: Re: Slammed by American Business Alliance Date: Sat, 29 Mar 1997 23:05:07 -0800 Organization: hypatia.com Mark Wold wrote: > Out of the blue, every other long distance call we started making was > getting 'all circuits busy'. so I call 1-700-555-4141 and find that > I'm on AT&T. We call Ameritech and they show a change to American > Business Alliance, an AT&T reseller. We track down these people and > register a complaint and a trouble call since we can't dial half the > calls we want. They are also known as 'The Phone Company'. They say > they have a verification firm which indicates that I authorized the > switch on 12/13/96 which took place on 03/11/97. I never authorized > anything. So they call back today and have produced a tape of a phone > call to our number with somebody claiming to be me. It's not me and > the conversation never happened. > I don't know what or who to believe. Either the verification firm > called a wrong number and somebody played the game as me, or the tape > was created as a fake. > Fortunately, Ameritech was able to get us back on our real carrier > within an hour. > Anybody else out there ever deal with these folks? They are based > somewhere in Pennsylvania. About a month ago, someone claiming to be "ATT" called to ask about how well I liked ATT, then passed me off to a person to get some personal information. I declined to give it, because it was too personal, like birthdate, SSN, etc., and because ATT should already have all the info they needed from me. The person was rather determined to get all this information but I firmly declined, so they gave me a number to call to prove that they were indeed who they said they were, and all, and it was not the published ATT service number. I think it was a scam, whether or not these people were associated with ATT. I think the intention was to slam me. With such a lengthy call, they could have recorded it and then cut-and-pasted their own version of me authorizing a switch. ATT already has all sorts of information about me (especially ATT -- formerly Bell -- Security) and they do not need any more, for any reason. These people gave absolutely no indication that they had any of this information, not address, not name, not anything. So I guess the obvious moral is, "Never believe that the caller is who (s)he represents herself to be". onymouse@hypatia.com | I've only one thing to say to spammers: "47USC227". Send NO spam | ------------------------------ From: J. DeBert Subject: Re: Fast Busy Signal Date: Sat, 29 Mar 1997 23:11:03 -0800 Organization: hypatia.com Scott Pakiser wrote: > We had a problem connecting to one long distance number (a "fast busy > signal" the carrier called it). We contacted the carrier and they > rerouted it within the hour. My question is: Is this a sign that the > carrier's network is either too small or unreliable? What exactly is > a fast busy signal? > It seemed strange that only one number was affected. It is the first > time to have a problem with the carrier, but we don't want it to > happen again. I'm not too sure about now, but not too long ago a "fast busy", aka "reorder" meant that no trunks were available to the destination or, sometimes, a dialing error. Each had it's own unique "fast busy" sound. Both have been mostly supplanted by voice messages, i.e., "...all circuits are busy..." and "...we are unable to connect your call as dialed...", etc. onymouse@hypatia.com | I've only one thing to say to spammers: "47USC227". Send NO spam | ------------------------------ From: Judith Oppenheimer Subject: Re: ISP Offering Unlimited Access via 800/888 - How?? Date: Sat, 29 Mar 1997 22:22:01 -0500 Organization: ICB Toll Free News Reply-To: joppenheimer@icbtollfree.com Wondering the same thing, I've been poking around since last month, checking RespOrg ID's, querying carriers, collecting contracts. Disparate findings are starting to make sense. A co-owner/systems administrator of a small ISP emailed me today, sharing, in part: "We bought into what is shaping up to be a big scam when we contracted with a company to provide us an 888 number for our dial in users at a flat rate per user per month. All parties involved have defaulted on the contracts and the FBI and secret service is involved." I spoke with a larger ISP yesterday, same story. Only this company had done thorough due diligence and follow-up. I have no documentation yet, but was told that RespOrgs involved knew they were being ripped off at least a month ago. Along, of course, with the victim ISPs and subscribers. Which raises all sorts of interesting questions. Judith Oppenheimer Robert, Holloman, Jr. wrote: > I just noticed on US Robotic's ISP list > (http://x2.usr.com/connectnow/index.html) there's an ISP called The > Grid (http://www.thegrid.net) offering unlimited, non-surcharged, > toll-free 800 access for a flat-rate of $24.95 per month. I've seen > another ISP planning to do the same. This sounds too good to be true. > Anyone had any experience with them? How the heck can they possible > afford to offer unlimited 800 service? Every ISP I've seen > (CompuServe, Concentric, MindSpring, etc., etc.) charges $5 to $10 > extra per hour for such. ICB TOLL FREE NEWS - 800/888/global800 news, analysis, advice. http://www.icbtollfree.com, mailto:news-editor@icbtollfree.com Judith Oppenheimer - 800 The Expert, ph 212 684-7210, fx 212 684-2714 mailto:j.oppenheimer@worldnet.att.net, mailto:icb@juno.com [TELECOM Digest Editor's Note: Could you give us a bit more detail on exactly how the scam or ripoff functioned? PAT] ------------------------------ From: Sheldon Laws Subject: Re: Modem to Modem Flow Control Date: Fri, 28 Mar 1997 00:38:33 -0800 Paul C. Diem wrote: > Can someone explain how modems implement flow control between each > other? The Clear to Send (CTS) signal tells the other modem that it is ready to get data from the other modem. The Data Set Ready (DSR) signal tells the other modem that it is going to send data. > For example, let's say I have modem A with a serial port speed > of 115200 which dials into modem B with a serial port speed of 19200 This is the speed at which each modem connects and send data to ITS computer. > and connects with a carrier of 28800.this is the speed that both > modems are communicating at with each other. > The system connected to modem A starts blasting data to modem A at > 115200, modem A starts sending data to modem B at 28800, modem B > starts sending data to the system connected to modem B at > 19200. Soon system B stops data flow No. Modem A would stop because modem b would be sending its data to its computer at a slower rate than A. > B's computer would be still getting the data(either > via hardware or XON/XOFF). XON/XOFF is considered software flow control, the software handles the controlling signals. > How does modem B tell modem A to stop sending data and later tell it > to start sending again? With the signals above,(CTS,RTS) if data is > at modem b and the computer is recieving it then modem B will tell > modem A to hold on till it is ready for more as well as modem A will > tell ITS computer to stop sending data to it untill it is ready to > send data to B There are two more signals that are used by the computers connected to each modem. They are (RTS) Request to Send, (DTR) Data Terminal Ready and then the send and recieve signals. the DTR is used by the computer to tell its modem that it is ready to recieve more data (from its modem) and the RTS tells its modem that it is going to send it data. the last signals are the actual send and recieve signals. ------------------------------ From: rapierce@X!pobox.com (Robert A. Pierce) Subject: Re: Does This Warning Really Make a Difference? Date: Sun, 30 Mar 1997 13:53:19 GMT Organization: Earthlink Network, Inc. Reply-To: rapierce@X!pobox.com The good Andrew C. Green sent these blessings: >> So how has it been going with you people who put those things >> in your messages? Has the spam and junk mail subsided at all? >> Are those idiots with their business opportunities and other >> worthless mail getting the hint at all? > Let's find out, shall we? I've planted a bogus return address in the > header of this message, to be used precisely once, right now. I expect > Incoming email sent to this "blackhole" address will bounce to our > long-suffering postmaster/SysAdmin, who has graciously agreed to keep When I first started modifying my address to "foil spammers," I was changing my user ID instead of the domain. It was pointed out to me that this would cause the mail be delivered to my ISP, and then bounced. I have started modifying the domain name of my email address. This causes the error to affect the sender's, and not the recipient's, ISP. I know of one person who uses "postmaster@localhost" as his reply-to address. I do not know if this works, but it is supposed to send the mail to the spammer's own ISP. If everyone would use the same name in the reply-to field, it would make things harder for the spammers. Something the spammers are doing now is subscribing to mailing lists, and getting the addresses via a "who." One list I am on received a message with over forty addresses in the "to:" field, and a one word message: "subscribe." Robert Pierce My e-mail address is antispam encoded. Remove the X! ------------------------------ From: jra@scfn.thpl.lib.fl.us (Jay R. Ashworth) Subject: Re: Can Rev J flash Rev K on BSP? Date: 29 Mar 1997 22:24:39 GMT Organization: University of South Florida [TELECOM Digest Editor's Note: The original message on this did not appear in the Digest. PAT] Broth101 (broth@execpc.com) wrote: > In article <332da53e.2496560@news.detroit.mi.ameritech.net>, > mascot@ameritech.net says... >> I liked the way my BSP worked better before I flashed it with Rev K. >> Is it possible to Flash the BSP with an older Revision, ala Rev J? > FWIW, we just got ISDN yesterday and the BSP's performance > improved *slightly* when we went from J to K. I went from > a 33.6 to ISDN, everything is hooked up right & running at > two channels... but if this speed is better than 56K, I'm > a monkey's uncle. > Is ISDN performance *completely* dependent on the speed of > the Net at a given time? I'm curious about your experience > with your BSP's speed. We're real disappointed so far. In general, it's a good idea to remember that the perceived response time of any given system will depend on the most restricted part. The faster your local "last-milee" lin becomes, the more you'll notice the limitations in the rest of the net. In many cases, the net throughput can in fact be less thatn 128Kbps, and occasionally, less than 64K. Much of the bog in the net as we know it today comes from the _vast_ lack of locality of reference in the peering amongst the major backbone providers. Mail from my commercial Mindspring account going to my free account on the local freenet has to go via New Jersey, because the two networks involved only touch at MAE EAST, in Pennsauken. This is inane and moronic, but it's a side effect of commercialism. All that extra traffic may well account for 50% or more than the backbone loading, and setting up more regional peering points would solve the problem ... but they don't seem to be inclined to _do_ that, much. Cheers, Jay R. Ashworth High Technology Systems Consulting Ashworth Designer Linux: Where Do You Want To Fly Today? & Associates ka1fjx/4 "...short of hiring the Unabomber, how can I +1 813 790 7592 jra@scfn.thpl.lib.fl.us get back at them?" --Andy Cramer NIC: jra3 ------------------------------ End of TELECOM Digest V17 #79 *****************************