Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id LAA00776; Fri, 23 Aug 1996 11:41:35 -0400 (EDT) Date: Fri, 23 Aug 1996 11:41:35 -0400 (EDT) From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor) Message-Id: <199608231541.LAA00776@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V16 #434 TELECOM Digest Fri, 23 Aug 96 11:41:00 EDT Volume 16 : Issue 434 Inside This Issue: Editor: Patrick A. Townson Some Thoughts on Custom Calling Features (Mark J. Cuccia) Re: Atlanta 911 and COCOTs: The Bomb Call Transcript (Bill Newkirk) Re: Atlanta 911 and COCOTs: The Bomb Call Transcript (Andrew C. Green) Re: GE 916 Wireless Phone Jack System (Mike O'Dorney) Re: Voicemail and Unix (David G. Lewis) Re: Selecting Local Telco (Wes Leatherock) Re: Why is the Internet So Slow? (Kevin E. Bertsch) Re: T1 Direct Dial In Standards (John Agosta) Re: Encryption and Telnet (Jason Gabler) One Suggestion For Dealing With Spammers/Junk Mailers (Babu Mengelepouti) ---------------------------------------------------------------------- Date: Fri, 23 Aug 1996 09:41:54 -0700 From: Mark J. Cuccia Subject: Some Thoughts on Custom Calling Features In "Pac*Bell: Speed Call 8 to Die", Robert McMillin wrote: > I got a letter yesterday informing me that Pac*Bell wants to terminate > its Speed Call 8 service offering in California. Existing > installations will continue to work, but if the rule change get > through the CPUC, new installations will not be available. The reason > given is that demand for this feature is low, since there are many > programmable phones out there. One reason might be that Speed-Call-8 uses 'single' digit codes to activate a call to that programmed number 'slot'. Most North American telcos (and switches) use the Bellcore recommendation of *-74 (11-74) _or_ 74-(#) to program a Speed-8 list, and *-75 (11-75) _or_ 75-(#) to program a Speed-30 list. The actual _use_ of Speed-8 involves dialing a single 'N' digit from '2' throught '9', and then either wait for 'time-out' or entering the DTMF '#' button, while actual _use_ of Speed-30 uses the digits '20' through '49', followed by the same 'time-out' wait which can be cut-through right away by entering the DTMF '#' button. At one time, use of the '11' digit or '*' button before the single digit Speed-8 entry or two-digit Speed-30 entry was intended (I think that Chicago did it this way in the ESS offices, twenty years ago in the mid-1970's), and I've been told that some DMS or #5ESS offices allow the _use_ of Speed-8/30 this way. Bellcore NANPA and INC/ICCF recommendations on "Vertical Service Codes" (also known as "star-x-x" codes) indicate that *-2X (11-2X) and *-3X (11-3X) as 'activation' or 'control' codes (as opposed to Speed-30 _use_) be reserved for future expansion to three-digit VSC's (i.e. *-2XX and *-3XX). This might be a reason why Pac*Bell is phasing out Speed-Calling-8, as well as maybe some customer confusion about other FCC mandated codes (*-67 and *-82). Some LEC's also offer feature packages for multi-line groups in a single home or business. Some of the features involved are "Call-Pickup" (answering a call on the 'other' ringing line) and "Call-Park" (putting a call on hold and answering it on the other line), and many other 'standard' vertical features are also included in these packages. BellSouth calls this package "Prestige". Activation and use of these package features involve the use of the '*', '#', and switch-hook flash. Answering Call-Waiting 'beep' on a "Prestige" number group is usually handled by 'flashing', _getting recall or 3-way dialtone_ and then entering a *-X or *-XX code to answer the 'beep', rather than just simply 'flashing' to answer. Many of these features are similar to some PBX features which have been available since the 1970's. When the FCC mandated *-82 (11-82) nationwide for allowing a number to display, regardless of the 'default' private or public status of a line's number, BellSouth had to change the '*-8' code for whatever "Prestige" feature used it to '*-8-#' to prevent any confusion with *-82. Another sidenote about BellSouth is regarding 'per-use' 3-Way Calling. I subscribe to 3-Way on a monthly flat basis. In #1(A)ESS offices, 'per-use' 3-Way Calling had to be activated _in advance_ of the call, by dialing 11-71 (*-71). You couldn't 'add-on' a third party during a conversation, unless you subscribed to monthly 3-Way, as you didn't have the use of 'flash' to bring in a recall dialtone. You also couldn't 'cancel' Call-Waiting during a call ('flash', wait for 3-Way dialtone, enter 11-70 or *-70), again as you didn't have 'flash' privilages for 3-Way dialtone _during_ a call in progress. DMS and #5ESS (digital) offices here never had the use of *-71/11-71 for 'per-use' 3-Way calling. You could _only_ subscribe on a monthly basis to 3-Way calling. Recently, BellSouth added Call-Return (*-69/11-69) and Repeat Dial (*-66/11-66) to _ALL_ customers. I subscribe to both on a monthly basis, however, so I wasn't affected. But customers who did _NOT_ subscribe on a monthly basis were charged 75-cents 'per-use' for *69 and *66! They _CAN_ get free blocking if they don't want the kids using these features. _AND_ BellSouth also added 'per-use' 3-Way Calling in Digital offices, but _NOT_ with the use of *-71/11-71, but giving those customers _FLASHING_ privilages to gain a 3-Way 'recall' dialtone! Visitors to a friend's house might think that their friend subscribes to 3-Way, since they get a recall dialtone when flashing, while they are actually putting a 75-cent charge on their friend's monthly bill if the 3-Way connection completes! This has recently caused a _LOT_ of confusion and angry customers, some who have had $20.00 to $30.00 per month of 'per-use' 3-Way Calls! And yes, you _CAN_ get 'per-use' 3-Way blocked. By the way, I do subscribe to _BOTH_ Speed-8 _AND_ Speed-30. I had Speed-8 for about two years, and then wanted to add Speed-30. This was about a year ago. It is possible to have both on the #1AESS that serves my home. But the service-rep at the Business Office thought I wanted to drop Speed-8. I had to tell her that I wanted _BOTH_ and I _DO_ have both! MARK J. CUCCIA PHONE/WRITE/WIRE: HOME: (USA) Tel: CHestnut 1-2497 WORK: mcuccia@mailhost.tcs.tulane.edu |4710 Wright Road| (+1-504-241-2497) Tel:UNiversity 5-5954(+1-504-865-5954)|New Orleans 28 |fwds on no-answr to Fax:UNiversity 5-5917(+1-504-865-5917)|Louisiana(70128)|cellular/voicemail [TELECOM Digest Editor's Note: What exactly is the purpose of having both, other than to be a little snobbish and peculiar? PAT] ------------------------------ From: Bill Newkirk Subject: Re: Atlanta 911 and COCOTs: The Bomb Call Transcript Date: Fri, 23 Aug 1996 09:24:54 -0400 Organization: Rockwell Avionics/Collins Reply-To: wenewkirk@rodes.cca.rockwell.com Howard Pierpont wrote: > Not sure if you have seen the transcript. interesting read. > howard Pierpont > Business Resumption MAnager, Digital Semiconductor > hudson MA. > ------ From RISKS DIGEST 18.35 ------ > Dispatcher: "Zone 5." > 911 Operator: "You know the address to Centennial Olympic Park?" Ok, there's the problem. 911 ops should be telling everyone they talk to that they've got a bomb report to file; not "how do you spell the park's name?" -- that could be someone didn't clean up their dog's poop. Much like the Eastern Airlines flight that crashed in south Florida because the entire crew got tied up trying to fix the "gear down" lamp and no one was flying the plane. > [TELECOM Digest Editor's Note: That situation in Atlanta was certainly > a tragedy which was no doubt compounded by the confusion expressed by > police dispatchers shown above. > One victim of the explosion is Mr. Jewell, the security officer who > was involved. As everyone knows by now -- I trust -- he was completely > innocent of any complicity in the affair, yet the FBI saw fit to put > him through an incredible smear job -- a common FBI tactic -- in order > to find him guilty in the eyes of the public. Must have been some of the Waco gang on this case ... just exactly when did the FBI start becoming the "shakiest gun in the west"? ------------------------------ Date: Fri, 23 Aug 1996 08:25:37 -0500 From: Andrew C. Green Subject: Re: Atlanta 911 and COCOTs: The Bomb Call Transcript Howard Pierpont writes: > I noted a discussion about LOTS of COCOTs being placed in ATlanta > before the Olympics. I haven't heard if the phone used was a COCOT, > but I think [based] on the way the 911 call was handled] it was. I don't see the significance here; I think your concern is misdirected. The problem the dispatchers were dealing with was that their system would not allow them to enter the bomb threat location without a valid street address for Centennial Park. The pay phone used (which did not look like a COCOT in news footage, FWIW) was at least two blocks away from the blast, so its address, whether displayed on the dispatcher's system or not, would not have been correct for Centennial Park in any event. Andrew C. Green (312) 266-4431 Datalogics, Inc. 441 W. Huron Internet: acg@dlogics.com Chicago, IL 60610-3498 FAX: (312) 266-4473 ------------------------------ From: modorney@aol.com (MODorney) Subject: Re: GE 916 Wireless Phone Jack System Date: 22 Aug 1996 17:05:23 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , Bill Newkirk writes: >> I don't remember the values we used to use back when I was involved >> with a carrier current radio station in college. Seemed like it was a >> 1000V cap (or maybe 1500 V) and on the order of 1 uF or so, maybe >> smaller. > I've since been informed that's there's a device available with the > right size caps in the form of a 220 V appliance adapter. I have solved this problem when I encountered it using X-10 controllers. I solved it by putting a 1 microfarad/1000 volt across the terminals on the dryer. I just unplugged my dryer and took off the cover to access the screws that connected the cord. I loosened the two hot screws (the middle screw is neutral) and installed the capacitor. This way, I did not have to work on a hot circuit, and I had an rf path from one side of the 220 to the other, since I (and most people) never unplug my dryer. Mike O'Dorney - Mikeod@scscom.com ------------------------------ From: dlewis@hogpc.ho.att.com (David G. Lewis) Subject: Re: Voicemail and Unix Date: 22 Aug 1996 12:36:45 GMT Organization: AT&T In article , Ferdinand Verbelen wrote: > Jailbait wrote: >> My big switch question is: >> WHY haven't they built TCP/IP support into phone switches yet? With a >> little bit of work you could make a secure system that could be >> programmed from the office of the person who does the programming work >> and not just from a dedicated terminal in the same room with the >> switch. If by "programmed" you mean "provisioned" (e.g. entering, viewing, and changing switch data), then the answer is "they have" (although some data networking protocol stack other than TCP/IP may be used); provisioning data into a telco central office from an onsite terminal is the exception, not the rule. If by "programmed", however, you mean "programmed" (i.e. changing the software that performs call control or other functions of the switch), then the answer is "you really don't want to." Think about it - if you leave a semicolon out of a c program on your workstation, you just fix and recompile. Worst case, you reboot the workstation. If you leave a semicolon out of a switch program you're rewriting, you could, say, take down half a long distance network ... (Strictly hypothetically, of course ...) Switch (and other telecom network element) software is designed, coded, built, and rigorously tested offline in what are referred to as "non-penalty environments" before being loaded into active network elements. AT&T operates an Integrated Test Network which is, in effect, a scale model of the AT&T LD network, strictly to test new features before deployment to the field. Once a feature is tested, it can, of course, be loaded remotely. We don't send techs out to all the switch sites with tapes to load software updates. But the development per se, and a ton of associated testing, is all done offline. David G Lewis AT&T Network & Computing Services david.g.lewis@att.com or Network Services Planning deej@taz.att.com Call Processing Systems Engineering The Future: It's a long distance from long distance. ------------------------------ From: wes.leatherock@hotelcal.com (Wes Leatherock) Subject: Re: Selecting Local Telco Date: Thu, 22 Aug 1996 14:02:16 GMT fgoodwin@tri.sbc.com (Fred Goodwin) wrote: > In article , xred@ix.netcom.com > (Theron Derx) wrote: >> Are you aware of any legislation pending, or in place now, that >> permits a person or a company to select their local telco? For >> example, if I live in Southwestern Bell country, but would prefer >> to have GTE, is there any legislation that would permit me to do >> that? If it is, (or will be in the future) will it work much the >> same way as the selection of an LD carrier? I would greatly >> appreciate any information you could send me. Thank you in >> dvance for your time. > At least in Texas, legislation was passed in 1995 that allows for > local competition. Potential competitors for the local exchange > business must apply to the Public Utility Commission of Texas for > authority to provide local service, whether by resale of the incumbent > carrier's service, or by providing their own facilities and services. > It just so happens that GTE recently applied for and received > permission to provide local service in most of Southwestern Bell's > operating territory in Texas. As for how you request service from GTE, > you probably need to talk to them. And in June Southwestern Bell applied to the Public Utility Commission to provide telephone service in "all or parts of several cities now served by GTE, including the Dallas-Fort Worth Airport and the suburban communities of Denton, Plano and Richardson." > Re: Pat's suggestion about FX service: everything he said is true, but > for FX customers here in Texas, an FX line gives the local calling > scope of the dialtone exchange, but does not provide local calling > within the exchange where the FX customer is physically located. > E.g., if you are located in Denton, TX (a GTE exchange) and you want > an FX line into Dallas (about 30 miles and a toll call away), SWBT > would provide you the FX line for all the local calling you can eat in > Dallas, but you cannot use it to make local calls in Denton (because > the dialtone is coming from Dallas, get it?) > So FX is really a replacement for toll service, not for local service. This is the way FX service works everywhere: that's why it's called "Foreign Exchange" service. You actually get service from the "foreign" exchange, by having a leased line from your telephone to the distant central office. There was an amusing story in the paper in Oklahoma City a number of years ago about people calling the number they had for a laundry (which had since gone out of business) and the number was answered "Washington," and the called party was somewhat annoyed by calls about laundry and cleaning and decline to answer any questions about what had been reached. It turned out the number was assigned now to the FBI's FX to their Washington, D.C., switchboard. Some businesses have found it cost effective for several different locations each to have FXs to a more or less centrally located (with respect to the various business sites) exchange where the business does not even have operations. Each location can then call another location by using their FX to call the other location's FX in the centrally-located city. Wes Leatherock wes.leatherock@hotelcal.com wes.leatherock@origins.bbs.uoknor.edu ------------------------------ From: Kevin E. Bertsch Subject: Re: Why is the Internet So Slow? Date: 22 Aug 1996 14:22:45 GMT Organization: Phonettix Intelecom Mark, The latest issue of {BYTE} as an excellent article that addresses this issue, as well as including a technical description of the new Internet addressing scheme. Hope it helps. Kevin ------------------------------ From: jagosta@interaccess.com (John Agosta) Subject: Re: T1 Direct Dial In Standards Date: 22 Aug 1996 15:13:14 GMT Organization: Agosta and Associates In article , Zohar Golan says: > I'm looking for the standards for Direct Dialing In (DDI or DID) in > digital T1 trunks. > If anyone can tell me where can I find those standards or what > standards I need, it would be very helpful to me. You may find what you are looking for in ATT 43801 which elaborates on all sorts of standard signaling schemes. Its been a while since I've looked in it myself. I remember, however, that there were about 13 pages of related signaling information for just about every trunk type you can imagine. ja ------------------------------ From: jygabler@ucdavis.edu (Jason Gabler) Subject: Re: Encryption and Telnet Date: 22 Aug 1996 15:35:33 GMT Organization: University of California, Davis Derek Balling (dredd@lawgiver.megacity.org) wrote: > We have a customer who has international locations using the Internet, > and I'm at a loss on who to turn to for help in my dilemma. The usual > places I might expect to find an answer have yielded none, so I'm > hoping that the readers of the digest may be able to help me out. > We have a customer with offices in Japan that wants to allow them to > use an encrypted telnet session with their American office. The basic > criteria for the software we're looking for is: > 1.) Windows-based client > 2.) HP9000 compatible server/daemon > 3.) Exportable > 4.) Secure > I hope someone out there may know where I can turn. STEL (Secure > TELnet, a product released by CERT-Italy) was great EXCEPT that it has > no windows based client. (Which for the purposes of our customer is a > requirement.) One solution to this might be an MD5 based kerberos suite. I believe MD5 is legally exportable (DO NOT use kerberos with DES, or RSA I also believe, out side the US and Canada because it will land you in jail). You can also, if Kerberos is as forgiving as it used to be, fairly easily insert your own encryption mechanism. Kerberos generally comes with encrypted session capability for telnet, rsh and rlogin. If anyone knows better the circumstances regaring exporting MD5 PLEASE correct me. As a side note, I telecommute over 128k isdn which is dialed directly into the University of California, San Francisco (UCSF) campus. I work, however, for UCDavis (70 mi NE). So my connections generally go thru the ISDN, UCSF's (a subnet and then their) backbone, out to the UC SMDS and then thru UCDavis (and occassionally across CERFnet orr BARRnet). That's alot of cable. Every login I do is fully encrypted. Lehitra'ot! Jason Gabler Home Office: 415-752-1969 (M-W,F) Programmer/Analyst Campus Office: 916-752-9215 (Th) Information Technology - DCAS E-Page: jygabler@dcaspager.ucdavis.edu University of California, Davis http://quadrophenia.ucdavis.edu ------------------------------ Date: Fri, 23 Aug 1996 00:05:57 PDT From: Babu Mengelepouti Subject: Suggestions For Dealing With Spammers and Junk Mailers >> Tim Luedtke >> Owner, First Look >> P.O. Box 770441 >> Orlando, FL 32877 >> (407)438-8892 Phone >> (407)438-7083 Fax > Call each provider in sucession (as he bombs you), and file formal > complaints. You might also want to contact your provider, explain the > situation, and have steps taken at their level to filter out anything > he would throw your way. As well, file a complaint with the FCC on the > grounds of harassment (indirectly, but harassment nonetheless) by > phone (since he is probably using a dial-up connection with AOL). While calling the providers is a good idea, it's ineffective to file a complaint with the FCC -- they won't do anything. On the other hand, it could be very productive to call his local police department and try to file charges for "phone harassment." Police detectives start to slobber when they hear about "internet crimes," especially if you tell them that this individual is a "hacker." They'll make up all kinds of nonsense to get search warrants and spend enormous amounts of time researching very petty things. You could even try to get a restraining order. The detective will probably even make up lies for you about what he's done to you, to make it even more convincing. > If you *really* want to get nasty, and don't mind paying for a few > telephone calls, dial up some fax-back services and have them send him > some rather large technical manuals via his fax number. It never hurts > to share information (at least not you). :-) While getting the police involved is probably going to be his worst nightmare (at the very least, if they're convinced that he's a "hacker" or even better yet an "internet terrorist," they'll raid his house, point a gun at him, wife, and kids, and use a very broadly written search warrant to seize everything even remotely electronic in the house, as well as any "hacker paperwork."), you could do something a bit less harassing perhaps -- call him collect repeatedly using all sorts of different carrier access codes (some carriers just don't understand the meaning of no!), and use fax-back devices to call his VOICE line. Some of them are very persistent and will call dozens of times trying to reach a fax machine. Of course, if you choose to harass him with fax-back devices and collect calls, use of a pay station is recommended. It's probably not illegal, though ... if his line isn't blocked for collect calls then he's inviting them, right? And you dialed the wrong number on the fax-back machine ... Our horribly misguided justice system can be a valuable ally in cases such as this one. It helps that many police detectives are basically dishonest, too ... they'll make up whatever they need to, in order to make themselves look good. [TELECOM Digest Editor's Note: Umm! It sounds funny, but I think it should be reserved for the cases where the 'hacker' really is a very bad person on the net. Most of the spammers/junk mailers are just not very savvy on netiquette; most of them can be trained with a little patience. Some are vicious and can't be trained however, and for those I would say your suggestion would be a real treat to watch, as one bunch of stumbling, bumbling fools is pitted against another stumbling, bumbling fool. PAT] ------------------------------ 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 mirror.lcs.mit.edu. The URL is: http://mirror.lcs.mit.edu/telecom-archives They can also be accessed using anonymous ftp: ftp mirror.lcs.mit.edu/telecom-archives/archives A third method is the Telecom Email Information Service: Send a note to tel-archives@mirror.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. ------------------------------ End of TELECOM Digest V16 #434 ******************************