Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id DAA12756; Tue, 13 Aug 1996 03:09:12 -0400 (EDT) Date: Tue, 13 Aug 1996 03:09:12 -0400 (EDT) From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor) Message-Id: <199608130709.DAA12756@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V16 #404 TELECOM Digest Tue, 13 Aug 96 03:09:00 EDT Volume 16 : Issue 404 Inside This Issue: Editor: Patrick A. Townson Expansion to Longer-than-Ten-Digits in NANP (Mark J. Cuccia) International Conference on Spoken Language Processing (Jim Polikoff) Convention Attendees Receive Wireless Welcome to San Diego (Mike King) New Wireless Phone Network Comes Through Power Outage (Mike King) Requesting Internet Fraud List (DVIEI1@jcpenney.com) Re: Reselling Cellular Airtime (Michael P. Mullineaux) DTMF Tone Keypads Wanted (David Michael) Telecom Instructors Needed at UC Berkeley Extension (course@berkeley.edu) Mixing Voicemail and Unix (Ed James) Re: Speaking About Crashes and Doing Dumb Things (Christopher Wolf) Re: Speaking About Crashes and Doing Dumb Things (Jon Solomon) ---------------------------------------------------------------------- Date: Mon, 12 Aug 1996 13:28:16 -0700 From: Mark J. Cuccia Subject: Expansion to Longer-than-Ten-Digits in NANP No, I don't have any specific plans, yet. The INC mailings I have been receiving talk about *various* possibilities for expanding from ten-digits, some of which include a "national destination code" (i.e. there would be a two-digit or three-digit code inserted between '+1' and the area code, indicating US, Canada, particular Caribbean location, etc), four (or more) digit area codes, four (or more) digit central office codes, five (or more) station line numbers, etc. There were also combinations of such, as well as discussions of *where* to tack on the additional digit(s) in a particular subset code. But I had been under the impression that we would tack a '0' or a '1' to the end of existing three-digit area codes, and that there would be a permissive period. Also, during the permissive period, I would have thought that N9X0, N9X1, and/or N9XN would have been the 'new' four-digit area codes. *IF* this would have been the case (current NPA codes using NXX-1 or NXX-0 as four digit area codes, during the permissive period), I was curious as to how non-line-number-based RAO/CIID calling cards would have been handled, unless *all* calling cards had gone to the mandatory use of the '89' format, described in earlier issues of the Digest. Since presently, no 0XX/1XX codes are used for *customer* dialable NANP POTS numbers, they are used for "special" calling cards, of the form NXX-1XX/0XX-xxxx plus PIN (nxxx). The first group, the NXX here, is the RAO or the beginning of the CIID in these card numbers. Also, operators and network test people use 0XX/1XX codes for internal network/system code purposes. All of this could cause a code ambiguity. However, James Bellaire recently stated what seems to be the most likely (and completely overlooked by me) way to give permissive dialing of current area codes into a four digit format. Since the N9X range are reserved for expansion purposes, current area codes (NyX, where y is not '9') would be permissively dialed as N9yX and as NyX. When mandatory use started, they would *have* to be dialed as N9yX, and new four-digit NPA codes would be assigned NyXX, where 'y' is any digit except '9'. I don't know what they would then reserve for *further* expansion from that, other than probably reserving another possible digit in the new 'four-digit' format. This method allows continued use of 1XX and 0XX codes for special calling cards as well as network/system routing codes without any ambiguity. I also recently spoke with someone (who wishes to remain nameless), who used to be with Bell Labs for some decades, and retired from Bellcore a few years ago. His area of work was in switching, but the areas related to the Numbering Plan. He had suggested a few years ago that the easiest way to expand to four-digit area codes, as far as memorization of rules goes, would be that when the NNX format of area codes was being planned for, to *reserve* those codes where the first and second digit are identical. i.e. 22X, 33X, 44X, 55X, 66X, 77X, 88X, 99X This is eighty codes, the same number reserved when using N9X. When the time comes when permissive dialing of four-digit area codes would come about, before any *new* four-digit area codes would be actually assigned, tell the customer to *double* their first digit. i.e. 312 would become 3312, 630 would become 6630, 847 would become 8847, 708 would become 7708, etc. There would not be any three-digit area codes 331, 663, 884, or 770 since those *would have been* reserved. The thinking was that it would be easier for everyone involved (telco and customer) to simply 'double' their NPA's first digit, rather than 'inserting' a specific digit somewhere inside the area code or tacked on to the end (such as what most likely will be happening, placing a '9' between the present first and second digits). However, Bellcore/NANPA/ICCF/etc. didn't follow that plan, as we've seen the introduction of: 330 Ohio, 334 Alabama, 440 Ohio, 441 Bermuda, 443 Maryland, 664 Montserrat, 770 Georgia, 773 Illinois, 880 "Caller-pays-800", 881 "Caller-Pays-888", 888 additional toll-free, and the various other codes in these ranges now reserved for "easy-to-recognize" (888, 777, 666, 444, 333, 222; 555 is now "unassignable"); and the 99X codes are more of the use of '9' in the middle reserved for expansion. With that never adopted proposal aside, If I remember correctly, all expansion plans for the total number of digits of an NANP number being discussed by the INC and other industry forums assume that the final length will be a *fixed* length number. True, we presently do have dialable strings of various lengths (0, 00, N11, 1/0+ten-digits, ten-digits, *-XX/11-XX prefixes, etc.), and a permissive period of three-digit and four-digit area codes would appear to be 'mixed' length, but an existing three-digit area code permissively dialed as three or four-digits would eventually (one year? six-months?) become a mandatory four-digit area code, as new codes assigned would be four-digits, thus a fixed-length system. It is always nice to know how many digits to expect when dialing a number, visually reading a number, or when quoting a number or hearing a quoted number. Use of timeouts, as well as instructing the use of the '#' to cancel/cut-thru right away is IMO always a nuisance. Of course, all of the above assume that we will continue to use 'traditional numbering', rather than some form of new technology or scheme, such as an "electronic directory" (similar to using a webpage to click a choice of URL's to visit). Also, other factors involved include number portability, etc. Whatever does happen during the evolution is the fact that 'numbering' or 'identification' will become less-and-less associated with the actual *switches* involoved, as well as geography or location. 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 ------------------------------ From: polikoff@asel.udel.edu (Jim Polikoff) Subject: International Conference on Spoken Language Processing Date: 12 Aug 1996 17:24:03 -0400 Organization: AI duPont Institute ICSLP 96 -- Update and Reminder Fourth International Conference on Spoken Language Processing ****** October 3-6, 1996 Wyndham Franklin Plaza Hotel Philadelphia, PA, USA ****** There is still time to register for ICSLP 96. ICSLP 96 offers a strong and diverse program covering all aspects of spoken language processing. ICSLP 96 presents an opportunity to keep up with the latest research and developments as well as network among other speech professionals. Registration information, as well as other information about the conference, can be found on our WWW site at http://www.asel.udel.edu/icslp/. This site provides registration forms, information about hotel accomodations, airfare information, and general information about Philadelphia as well as listings of the full contents of the technical program. _____________________Registration Information______________________________ Full registration includes: Admission to technical sessions, Reception, Banquet, Proceedings (printed & CD-ROM) Limited registration includes: Admission to technical sessions, Reception, Proceedings on CD-ROM Early Registration fees: Member* Non-Member Student Full $425 $525 $250 Limited $300 $400 $150 Late registration: After July 1, add $60 After August 9, add $100 Additional Tickets: Banquet $60 Reception $50 Additional Proceedings: Printed $125 CD-ROM $15 * Sponsoring and Cooperating Organizations: The Acoustical Society of America The Acoustical Society of Japan American Speech and Hearing Association Australian Speech Science and Technology Association European Speech Communication Association IEEE Signal Processing Society Incorporated Canadian Acoustical Association International Phonetic Association Linguistic Society of America ICSLP 96 A.I. duPont Institute P.O. Box 269 Wilmington, DE 19899 E-mail: ICSLP96@asel.udel.edu URL: http://www.asel.udel.edu/icslp/ Phone: +1-302-651-6830 Fax: +1-302-651-6895 ------------------------------ From: Mike King Subject: Convention Attendees Receive Wireless Welcome to San Diego Date: Mon, 12 Aug 1996 14:40:32 PDT Forwarded to the Digest FYI: Date: Mon, 12 Aug 1996 11:39:38 -0700 From: sqlgate@list.pactel.com Subject: Convention Attendees Receive Wireless Welcome to San Diego FOR MORE INFORMATION: Linda Bonniksen (213) 975-5061 John Britton (619) 237-2430 Convention Attendees Receive Wireless Welcome to San Diego Mayor Golding Uses Pacific Bell Mobile Services PCS Phone to Send a Text Message SAN DIEGO, Calif. - Using PCS, a digital wireless telecommunications technology from Pacific Bell Mobile Services, Mayor Susan Golding today delivered a short-text message welcoming the Republican National Convention to San Diego. Message Sent to 600 PCS Phones Mayor Golding sent her welcome message at 6 a.m. The 85-character message appeared on the screens of approximately 600 PCS phones being used at the convention. "San Diego is America's city of the future so it couldn't be more appropriate for PCS to premiere here at the same time we host the Republican National Convention," Mayor Golding said. "I am thrilled that Pacific Bell Mobile Services brought this exciting new technology to our city first." "Since July 1, more than 200,000 calls have gone through the Pacific Bell Mobile Services network," said Lyn Daniels, president and chief executive officer of Pacific Bell Mobile Services. "When it comes to technology, PCS is the hot property." The digital wireless technology is called Personal Communications Service (PCS), a more reliable and secure alternative to cellular. The service makes its California debut this week at the Republican National Convention where Pacific Bell Mobile Services is the official provider of wireless telecommunications services. The Republican National Convention and Pacific Bell Mobile Services have distributed more than 600 PCS phones among convention organizers, party officials, candidates, security agencies and media. Pacific Bell Mobile Services activated PCS service for the convention last month. The coverage area includes the San Diego Convention Center, downtown hotels, tourist attractions, the airport, major transportation corridors and the coastline. Convention attendees are using their PCS phones to send and receive calls and short-text messages. The phones can also be plugged into laptop computers for wireless faxing and Internet access. After the convention closes, Pacific Bell Mobile Services will prepare for a consumer product launch in California and Nevada in early 1997. The company plans to broadly distribute PCS phones through drug stores, consumer electronics stores and warehouse retailers. Industry analysts expect PCS to cost less than existing cellular service, particularly in California where cellular subscribers pay among the highest rates in the nation. Pacific Bell Mobile Services is the wireless communications subsidiary of Pacific Bell. Pacific Telesis Group, the parent company of Pacific Bell and Pacific Bell Mobile Services, is a diversified telecommunications company headquartered in San Francisco. ------------- Mike King * Oakland, CA, USA * mk@wco.com ------------------------------ From: Mike King Subject: New Wireless Phone Network Comes Through Power Outage Date: Mon, 12 Aug 1996 14:41:04 PDT Forwarded to the Digest FYI: Date: Mon, 12 Aug 1996 11:48:44 -0700 From: sqlgate@list.pactel.com Subject: New Wireless Phone Network Comes Through Power Outage FOR MORE INFORMATION: Linda Bonniksen (619) 917-0951 - PCS Phone (619) 237-2430 John Britton (619) 917-1048 - PCS Phone (619) 237-2430 New Wireless Phone Network Comes Through Power Outage Pacific Bell Mobile Services Reports 100 Percent Increase in Call Volumes at Republican National Convention SAN DIEGO, Calif., -- Pacific Bell Mobile Services announced today that its new wireless phone network serving the Republican National Convention performed flawlessly through yesterday's power outage affecting nine western states. When the power outage occurred at 3:45 a.m. Saturday, 25 antenna sites in San Diego automatically switched from a commercial power source to their on-site back-up batteries. Additionally, the company's master switching center in San Diego and its network operations center in Pleasanton, Calif., switched to diesel generators. As a result, the company's new Personal Communications Services network stayed on the air to process 8,000 calls from 3:45 p.m. to 7:15 p.m., a 100 percent increase in calls from the same time period Friday. Pacific Bell Mobile Services is the official provider of wireless telecommunications services for the Republican National Convention. "The network didn't miss a beat," said Frank Casazza, operations vice president for Pacific Bell Mobile Services. "We built back-up power sources into the network for exactly these types of crises, and our planning paid off. More than 600 people using our Personal Communications Services at the Republican Convention made call after call after call without any interruption or delay." Personal Communications Services (PCS) is a new wireless telecommunications technology that offers a secure and private alternative to cellular. Unlike cellular, PCS is 100 percent pure digital. Being digital, PCS offers superior sound quality and reliability, as well as built-in complex encryption for maximum privacy and protection from cloning. The Republican Party and Pacific Bell Mobile Services have distributed more than 600 PCS phones to party officials, candidates, their staffs, event organizers, city officials, security agencies and the news media. Pacific Bell Mobile Services is the wireless communications subsidiary of Pacific Bell. Pacific Telesis Group, the parent company of Pacific Bell and Pacific Bell Mobile Services, is a diversified telecommunications company headquartered in San Francisco. ------------ Mike King * Oakland, CA, USA * mk@wco.com ------------------------------ From: DVIEI1@jcpenney.com Date: Mon, 12 Aug 1996 11:38:44 -0500 Subject: Requesting Internet Fraud List Would somebody know if there is a list of actual cases in which the Internet was used as a fraud tool against enterprises? (i.e.: theft, viruses, security breaches, etc...) Thanks. Cordially, Demian Vieira de Souza - Comm Analyst JCPenney Communications Systems 12700 Park Central Place M/C 6009 Dallas, TX 75252, USA Office:(214)591-7361 FAX:(214)531-7361/591-6721 Internet: DVIEI1@JCPENNEY.COM / PROFS ID: DVIEI1 ------------------------------ From: michael.p.mullineaux@arthuranderson.com Date: 12 Aug 96 11:48:06 GMT Subject: Re: Reselling Cellular Airtime Dear Readers, I am searching for additional information on cellular reselling; have your inquiries/responses generated any addtional data that you might share? Kind Regards, Mike ------------------------------ From: David Michael Subject: DTMF Tone Keypads Wanted Date: Tue, 09 Aug 1996 04:08:37 +0100 Organization: OiT Ltd. Hi, I want to purchase about 1,000 DTMF tone keypads (you know the things you get with your answerphone), but I only want to spend about $3 max. Does anyone know of a good cheap supply? Thanks, David Michael http://www.oit.co.uk/~david Technical Director, OiT Ltd. tel: +44 1865 785002 Oxford OX4 2JZ, UK fax: +44 1865 785100 ------------------------------ From: course@garnet.berkeley.edu Subject: Telecom Instructors Needed at UC Berkeley Extension Date: 13 Aug 1996 01:10:06 GMT Organization: University of California, Berkeley INSTRUCTORS NEEDED for... *** UC BERKELEY EXTENSION'S *** Telecommunications Engineering 4-Month Diploma Program UC Berkeley Extension is seeking part-time instructors to teach daytime credit courses in Berkeley. The 4-Month Diploma Program in telecommunications engineering is an intensive, focused program, developed for both international and residential students to complete in a concentrated time frame. The curriculum is designed to provide an in-depth understanding of telecommunications essentials and to develop a technical awareness of current practices and future directions. If you are a highly-qualified and experienced telecommunications professional, with a bachelors or higher degree, successful teaching/ training experience, and the desire to teach, we would like to hear from you. We are particularly looking for people with experience in: Data Communication; Computer Networks; Digital Telecommunications; Broadband Communications; Advanced Local Area Computer Networks; Internetworking; Wireless/Mobile Communications; Design and Applications of Mobile Data Networks. IF YOU ARE INTERESTED ... FAX your resume to (510) 642-6027 with a covering note mentioning your interest in teaching in the 4-Month Telecommunications Engineering Diploma Program. Please be sure that the resume specifies your experience as it relates to this program. Or send your resume ELECTRONICALLY to course@garnet.berkeley.edu (attn: 4-Month Telecommunications). Please mention your interest in teaching in the 4-Month Telecommunications Engineering Diploma Program. You may send your resume to us by snail mail at the following address: 4-Month Telecommunications Engineering Diploma Program c/o UC Berkeley Extension Engineering 1995 University Avenue Berkeley, CA 94720-7010 ------------------------------ Date: Mon, 12 Aug 1996 18:29:48 -0700 From: Ed James Organization: Migration Software Subject: Voicemail and Unix Has anyone had any experience hooking a unix box up to a vociemail system that isn't designed for it? Specifically. I have a NorTel Startalk of some configuration (floppy, scsi port on the back, parallel port, one card with two lines connected, labeled 1-2 and 3-4), and I would like to have it send email to folks when they get voicemail. Most of our employees are at client sites, and checking one's voicemail daily can be cumbersome. I'd like to instead deliver a piece of email to the mailbox owner that indicates that new voicemail arrived at a certain time. If I could hook the unix box up to the parallel port of the Startalk, and if I could convince the startalk to generate reports on a daily basis (or more frequently), I could parse the report on the unix side, and generate the required voicemail. I have no idea how to make the startalk do this, though. Does anyone out there have any experience with the startalk? Can it be made to generate reports regularly, and can they be easily directed to the parallel port for "printing"? Thanks in advance, ed ------------------------------ Date: Mon, 12 Aug 1996 09:53:41 CDT From: Christopher Wolf Subject: Re: Speaking Ahout Crashes and Doing Dumb Things On Thu, 8 Aug 1996, TELECOM Digest Editor wrote: > Last Sunday night I got on line about 10:00 p.m. here to do some work > on the Digest and I had a bright idea about a new script I wanted to > try out. Well the script flubbed, which was not anything unusual for > scripts that I write or try to hack on, but the main annoyance was > it left me with a directory full of about a hundred .h, .c. and .o > files to clean out when I decided to quit the experiment. > Now, I try to be smart with potentially disasterous commands like > 'rm' and I personally have 'rm' aliased to 'rm -i' meaning to not > erase a file without asking for confirmation. The problem is, if > you have a whole directory full of garbage files to get rid of > then if you go to that directory and do 'rm *' it will stop over > and over again, asking about each file. The command 'rm -f' will > NOT overrride 'rm -i' on this machine at least, although 'rm -f' > will work in a script running in the background with its own shell > regardless of what arguments I happen to have attached to 'rm' > for my use in the foreground. > So far so good. Instead of having to answer 'y' a 120 times for > every garbage file in the garbage directory I am abolishing, I > decided just this one time I would unalias 'rm' instead. So I > did 'unalias rm' then I did 'rm *' -- but the trouble is I had > ** forgotten to change directories to the one I wanted **. Pat, I use the idea of a trashcan when I activate remove. I alias rm to be the following script, which actually moves files to a hidden directory called .trashcan in my home directory and removes directories and symbolic links. Doesn't handle the more complex forms of rm, but it works fine. BTW: I also run a crontab job to clean out the directory every morning ... 20 4 * * 1-5 (/bin/rm /home/cwolf/.trashcan/* /home/cwolf/.trashcan/.??* > /dev/null ) If you use tcsh or csh like I do, you can then use \rm when you want to override the alias. A backward slash before a command means to ignore any aliases for it. #!/usr/local/bin/tcsh -f foreach i ($*) if (-d $i) then echo Removing directory $i /bin/rmdir $i else if (-l $i) then echo Unlinking symbolic link $i /bin/rm $i else if (-f $i) then if (`/bin/ls -l $i | /bin/cut -c23-31` > "500000") then set SIZE=`/bin/ls -l $i | /bin/cut -c23-31` echo -n "NUKING $i of size $SIZE. " /bin/rm $i echo "BOOM! No Backup." else echo Removing file $i to temporary trashcan. /bin/mv $i ~/.trashcan endif endif end ------------------------------ From: jsol@eddie.mit.edu Subject: Speaking About Crashes and Doing Dumb Things Date: Mon, 12 Aug 96 16:53:02 EDT Here's how to avoid this in the future: % mkdir .backup Copy all the files you want to save into that directory. Put the dot before it so you don't accidentally delete it. Then make .backup2, which should contain a copy of all incoming mail in .backup2/inbox. Clean this out every so often. This way you should not need the backups. ------------------------------ 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 #404 ******************************