Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id UAA21706; Tue, 4 Nov 1997 20:07:05 -0500 (EST) Date: Tue, 4 Nov 1997 20:07:05 -0500 (EST) From: editor@telecom-digest.org Message-Id: <199711050107.UAA21706@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V17 #301 TELECOM Digest Tue, 4 Nov 97 20:07:00 EST Volume 17 : Issue 301 Inside This Issue: Editor: Patrick A. Townson Book Review: "DNS and BIND" by Albitz/Liu (Rob Slade) Re: Sausage Making, SS7 and Protocols (Jay R. Ashworth) Uruguay Numbering Plan Changes (egoni@zfm.com) Phase-out of 10XXX Codes? (Linc Madison) UCLA Short Course on "Commercial Satellite Coommunications" (Bill Goodin) Re: NPA for Windows Update (Paul Cook) Book Review: "The VRML Sourcebook" by Ames/Nadeau/Moreland (Rob Slade) Re: Switch Information Requested (Mark J. Cuccia) Sprint Tops in Customer Satisfaction (Chuck Tyrrell) Canadian Area Codes (S. Hayman) 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: * telecom-request@telecom-digest.org * 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-727-5427 Fax: 773-539-4630 ** Article submission address: editor@telecom-digest.org ** Our archives are available for your review/research. The URL is: http://telecom-digest.org 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 archives@telecom-digest.org 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. Please make at least a single donation to cover the cost of processing your name to the mailing list. 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: Tue, 04 Nov 1997 10:23:30 EST From: Rob Slade Subject: Book Review: "DNS and BIND" by Albitz/Liu BKDNSBND.RVW 970705 "DNS and BIND", Paul Albitz/Cricket Liu, 1996, 1-56592-236-0 %A Paul Albitz %A Cricket Liu %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 1996 %G 1-56592-236-0 %I O'Reilly & Associates, Inc. %O U$32.95/C$46.95 800-998-9938 707-829-0515 fax: 707-829-0104 nuts@ora.com %P 438 %T "DNS and BIND", 2nd ed. Of the millions of users on the Internet, almost all are blissfully unaware of the complexity and magnitude of the task of network routing. How does the network know where to deliver a piece of email? In fact, given the packet nature of all Internet traffic, how do telnet or ftp packets get, reliably and generally quickly, to their destination? Few even recognize the term DNS, the Domain Name Service, which handles the problem. Administrators may have used BIND, the Berkeley Internet Name Domain program, to manage DNS, but may not fully understand the importance, use or finer aspects of it. This book gives both background and operational details. Given the nature of the network routing problem, a full understanding of DNS likely requires actual hands-on work. Albitz and Liu have, however, put together clear, straightforward, and sometimes even lighthearted text to make the learning process as painless as possible. The book also covers more advanced topics than straightforward routing administration. This new edition deals in fair depth with Windows NT, rapidly rising in importance to internetwork operation. Bind 4.8.3 is the basic version for the book, but there is complete coverage of Bind 4.9.4 as well. copyright Robert M. Slade, 1995, 1997 BKDNSBND.RVW 970705 ====================== roberts@decus.ca rslade@vcn.bc.ca slade@freenet.victoria.bc.ca link to virus, book info at http://www.freenet.victoria.bc.ca/techrev/rms.html Author "Robert Slade's Guide to Computer Viruses" 0-387-94663-2 (800-SPRINGER) ------------------------------ Date: Tue, 4 Nov 1997 12:28:07 -0500 From: Jay R. Ashworth Subject: Re: Sausage making, SS7 and protocols Organization: Ashworth & Associates, St Pete FL USA On Tue, Nov 04, 1997 at 07:12:27AM -0600, on the North American Network Operators Group mailing list, Sean Donelan wrote: >> In a world where the internet industry is becoming more and more >> like the telecoms industry, the necessity of users to have protocol >> level access to the network is diminishing, and the dangers of doing >> so are becoming greater. Which telcos will blithely hand out SS7 >> interconnects to users? Without (routable) IP access, there would be >> no SYN floods of distant networks, no source spoofing, less hacking, >> easier traceability, and the BGP table need only be OTO 1 entry per >> non-leaf node on a provider interconnection graph. > Strange how people in the telecom industry think they need to > become more like the internet industry, and people in the internet > industry think they need to become more like the telecom industry. > If you want to see some sausage being made, take a look at the > "Advance Intelligent Network" and the Internet interface working > group PINT. As someone who's spent extensive time in the past ten years following both industries, I'm going to have fun with this one ... To respond first to the original poster's question: "Which telco's will hand out SS7 connections to users", I pose the analogous question: "Which ISP's will hand out BGP4 connections to users?" > In the US, with telecom deregulation, the distinction between 'users' > and 'telephone companies' is becoming less distinct. When an insurance > company, an university, or an ISP files the paperwork to become a CLEC, > are they a 'user' or a 'telco?' What telco would refuse SS7 interconnects > to a CLEC? The trust model in SS7 makes rlogin look like a high-security > protocol. SS7 was developed in an environment where there would be a > few trusted 'users.' As the number of 'telco'-like entities explodes, > you might see some interesting security issues showing up with SS7. There > is some 'screening' between networks, but gateway STP nodes have many of > the same problems as Internet firewalls. Precisely. All an STP (Signal Transfer Point, for the non telco people) is, is an SS7 router. SS7 is, of course, the protocol used on the networks whereby switches tell each other about, and what to do about, calls. As Sean notes, this has been a tightly closed network to date, and whether sufficient engineering has been done to determine how scalable the administrative protocols surrounding it are is unknown. It's been noted that when you scale a problem up by an order of magnitude, it's no longer the same problem. Let's hope they don't blow this on SS7. > Internet providers give both less and more access to their networks than > telcos. Generally ISPs don't give other ISPs more access to their networks > than any other untrusted user. Even read-only SNMP between providers is > almost non-existant. Most ISPs would probally consider giving SS7 level > access into their network to another ISP a huge security hole. In some > sense, interconnecting ISPs is easier than telcos because the security > risk of connecting to another ISP is the same as connecting to a user. > Today's SS7 network is far more risky than anything Capt. Crunch could > do with his whistle. Perfectly correct. See, Sean? We do agree on some things. :-) > On the other hand, it seems like many ISPs don't consider it a duty to > screen or filter their customer's ingress or their own egress. While > telco's almost always screen information such as directory numbers when > they originate from a customer PBX. Yeah, but they didn't think it up until _afterwards_. It is to this day possible to spoof ANI/CNID with certain PRI connected PBXs on certain models of switch. > This has less to do with the SS7 > protocol, than the trust relationship between telcos. Telcos trust > other telcos to only send SS7 packets with screened customer phone > numbers. This 'trust' is formalized into extremely complicated > agreements between telcos, especially who is liable when the trust is > broken. ISPs have very simple 'trust' relationships (i.e. trust no one), > and correspondingly simple agreements between them. Excellent capsulization of the situation. > Since there is a much lower trust relationship between ISPs, tracing > malicious behavior is much more difficult. At a simple level, look how > caller-id information is treated between telcos. Telcos pass caller-id > information, more or less, on an end-to-end basis through the SS7 network > 'sharing' it with all the telco's along the way. However, telcos don't > pass the caller-id information to the 'user' if the presentation-restricted > flag is set. ISPs don't normally provide any more information to another > ISP than they do to an user. Which model causes less problems when the > CLEC turns out to be an private investigative company, or a university. Indeed. In the environment we're transitioning into, the ISP model will likely turn out to be more popular, for precisely that reason. Whether the LECs and IXCs can adapt is another question entirely. > It will be interesting to see which trust model works better as the > number of CLECs grows or the number of ISPs shrinks, depending on > which consulting group you want to believe. Will ISPs start trusting > each other more, or will telcos start trusting each other less? At > some companies, the Internet connection is the most secure outside > communications connection they have. Wow. That's a scary thought. I personally am disinclined to false senses of security, myself, so I prefer the latter. Lends an interesting tenor to the national security communications backbone topic, though, doesn't it? [ Cross posted from NANOG to comp.dcom.telecom, for comment. ] Cheers, Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592 ------------------------------ Date: Mon, 03 Nov 1997 17:48:23 -0300 From: Enrique Subject: Uruguay Numbering Plan Changes There has been some changes in the numbers of Uruguay this year. From October 26, all of the numbers from Montevideo got an extra digit, and also some of the nearby cities were aggregated to the same area code 2. Full info can be seen at http://www.7cifras.com.uy/7c_eng.htm I am also sending an updated list of city codes of Uruguay, complete as far as I know. Montevideo is the capital city, and I do not include the neighborhoods. Nevertheless, I do list some of the surrounding cities that also begin with 2 as city code. To dial a number in Uruguay from abroad, you'd dial +598-CityCode-Number To dial it from within Uruguay, you'd dial 0-CityCode-Number (if you're not in the same city you're calling to), or just Number, if you're in the same city. Uruguay Country Code : +598 City Codes : 2 Montevideo 2362 La Paz 2364 Las Piedras 2367 Melilla 2368 Progreso 2682 San Jose de Carrasco 2695 Solymar 2696 Solymar 2698 El Pinar 2292 Pando 2293 Totoral 2294 Sauce 2295 Empalme Olmos 2296 Toledo 2297 Surez 2298 Barros Blancos 338 25 de Agosto 3392 25 de Mayo 3398 Cardal 33950 Mendoza 33951 Mendoza Chico 3102 San Ramn (Ruralcel) 3103 Santa Rosa (Ruralcel) 3105 Tala (Ruralcel) 3109 Chamizo (Ruralcel) 3112 Casup 3116 Fray Marcos 3118 Pueblo Bolvar 3119 Reboledo 312 San Ramn 3132 Santa Rosa 3136 San Bautista 3139 San Antonio 315 Tala 3172 Migues 3175 Montes 318 Cerro Colorado 319 Chamizo 3308 25 de Agosto (Ruralcel) 3309 25 de Mayo (Ruralcel) 332 Canelones 334 Santa Luca 335 Joanic 336 Los Cerrillos 3402 San Jose (Ruralcel) 3405 Libertad (Ruralcel) 3406 Rafael Perazza (Ruralcel) 3407 Autdromo (Ruralcel) 3408 Rodriguez (Ruralcel) 342 San Jose 345 Libertad 3459 Puntas de Valdez 346 Rafael Perazza 2347 Autdromo (San Jose) 348 Rodriguez 349 Ecilda Paullier 3502 Florida (Ruralcel) 3504 Sarand Grande (Ruralcel) 352 Florida 354 Sarand Grande 3602 Durazno (Ruralcel) 3604 Trinidad (Ruralcel) 362 Durazno 363 Sarand del Y 364 Trinidad 365 Carmen 366 Paso de los Toros 368 Molles 369 San Gregorio de Polanco (Tacuaremb) 3702 Atlantida (Ruralcel) 3708 La Tuna (Ruralcel) 372 Atlantida 373 La Floresta 374 Soca 375 Parque del Plata 376 Salinas 377 Piedras de Afilar 378 La Tuna 379 Soles de Mataojo 3902 Pando (Ruralcel) 3909 San Jacinto (Ruralcel) 3992 San Jacinto 3999 Tapia 4102 Maldonado (Ruralcel) 422 Maldonado 423 Maldonado 424 Punta del Este 426 San Carlos 4270 La Barra de Maldonado 4271 La Barra de Maldonado 4278 Portezuelo 4279 Portezuelo 428 Punta del Este 429 Punta del Este 432 Piripolis 434 Pan de Azcar 438 Jaureguiberry / Balneario Soles 439 Gregorio Aznrez 442 Minas 444 Aigu 447 Batlle y Ord Fez 447 Zapicn 449 Mariscala 452 Treinta y Tres 453 Santa Clara de Olimar 454 Cerro Chato 455 Jose Pedro Varela 456 Lascano 457 Velazquez 458 Vergara 459 Cebollat 472 Rocha 473 La Paloma 474 Chuy 475 Castillos 47620 Punta del Diablo 47621 Santa Teresa 47627 La Coronilla 47628 La Coronilla 47629 La Coronilla 4806 Faro Jose Ignacio (Ruralcel) 486 Faro Jose Ignacio 4902 Piripolis (Ruralcel) 5202 Colonia (Ruralcel) 5204 Tarariras (Ruralcel) 5205 Colonia Miguelete (Ruralcel) 522 Colonia 574 Tarariras 575 Colonia Miguelete 576 Ombes de Lavalle 577 Conchillas 5302 Mercedes (Ruralcel) 5304 Dolores (Ruralcel) 5306 Cardona (Ruralcel) 5307 Palmitas (Ruralcel) 5308 Jose Rod (Ruralcel) 5309 Ismael Cortinas (Ruralcel) 532 Mercedes 534 Dolores 536 Cardona 537 Palmitas 538 Jose Rod 539 Ismael Cortinas 542 Carmelo 544 Nueva Palmira 5502 Rosario (Ruralcel) 5506 Juan Lacaze (Ruralcel) 5507 Playa Fomento (Ruralcel) 552 Rosario 554 Nueva Helvecia 558 Colonia Valdense 586 Juan Lacaze 587 Playa Fomento 5602 Fray Bentos (Ruralcel) 5607 Young (Ruralcel) 5608 Nuevo Berln (Ruralcel) 5609 San Javier (Ruralcel) 562 Fray Bentos 567 Young 568 Nuevo Berln 569 San Javier 6202 Rivera (Ruralcel) 622 Rivera 624 Vichadero 626 Tranqueras 628 Minas de Corrales 632 Tacuaremb 6382 Tambores 64 Melo 675 Ro Branco 679 Lago Mern 688 Fraile Muerto 7202 Paysand (Ruralcel) 722 Paysand 73 Salto 7302 Salto (Ruralcel) 7407 Piedras Coloradas (Ruralcel) 742 Guichn 7504 Quebracho (Ruralcel) 754 Quebracho 764 Constitucion 766 Beln 772 Artigas 776 Baltasar Brum 777 Toms Gomensoro 778 Mones Quintela 779 Bella Unin 94 Movicom (Celular) 982 Zona Franca de Montevideo 996 Ancel (Celular) ------------------------------ From: Telecom@LincMad.NOSPAM (Linc Madison) Subject: Phase-Out of 10XXX Codes? Date: Mon, 03 Nov 1997 13:30:08 -0800 Organization: LincMad Consulting; change NOSPAM to COM Is there a phase-out date set yet for the elimination of the existing 10XXX carrier codes in favor of the new 101XXXX codes? I got a mailing from the "Dime Line" folks (whom I do not recommend, BTW) and noticed that the little stickers now say "DIAL 1010-811" instead of "DIAL 10811". Background: Long-distance companies and other companies have been assigned five-digit prefix codes 10XXX to allow the caller to specify the carrier on a per-call basis. We're running out of 10XXX codes, though, so we're switching to 101XXXX codes. All existing codes are expanded to 1010XXX with the same last three digits. New codes are being assigned in the 1015XXX range, with other ranges to be opened after 10XXX codes are discontinued. Also, after the discontinuation of 10XXX, will all codes be 101XXXX, or will they at some point generalize to 10XXXXX? (Where do I sign up for my own code, so my friends can dial 10XXXXX-0-# if they don't want to bother with my 800 number? ;-P ;-b ;-P ) ** Do not spam e-mail me! ** Linc Madison * San Francisco, California * Telecom@LincMad-com >> NOTE: if you autoreply, you must change "NOSPAM" to "com" << ------------------------------ From: bgoodin@unex.ucla.edu (Bill Goodin) Subject: UCLA Short Course on "Commercial Satellite Communications" Date: Mon, 03 Nov 1997 18:37:55 GMT Organization: University of California, Los Angeles On January 26-30, 1998, UCLA Extension will present the short course, "Commercial Satellite Communications: Systems and Applications" on the UCLA campus in Los Angeles. The instructors are Bruce R. Elbert, Hughes Space & Communications, David A. Baylor, DirecTV, and David Bell, NCP Computers. Each participant receives the course textbook, "The Satellite Communication Applications Handbook", B. Elbert (Artech House, 1997), and extensive course notes. This course provides a state-of-the-art review of satellite communications technologies from a system perspective. Intended for practicing engineers in the satellite communications industry as well as major private and governmental users of satellite and terrestrial telecommunications services, it covers all aspects of the design, operation and use of satellite networks, with a heavy emphasis on commercial applications. The latter include television transmission and broadcasting (distribution and direct-to-home), voice and data networks using Very Small Aperture Terminals (VSATs), mobile satellite services, and advanced broadband capabilities of satellites under development. Each of the five days is broken down into a major segment to provide background in the engineering fundamentals, a detailed review of the current applications and implementations, and evolution of the technology and use of satellite systems in the coming millennium. Course topics include: Evolution of Satellite Technology and Applications Satellite Links and Access Methods The Range of Television Applications Interactive Voice and Networks Telephone Services by Satellite Mobile Satellite Communications--GEO and Non-GEO Broadband and Multimedia Systems How to Stay Abreast and Valued in the Satcom Industry The course fee is $1495, which includes the course text and extensive course materials. These materials are for participants only, and are not for sale. For a more information and a complete course description, please contact Marcus Hennessy at: (310) 825-1047 (310) 206-2815 fax mhenness@unex.ucla.edu http://www.unex.ucla.edu/shortcourses This course may also be presented on-site at company locations. ------------------------------ Reply-To: From: Paul Cook Subject: Re: NPA for Windows Update Date: Mon, 3 Nov 1997 08:32:29 -0800 I wrote: > The latest release for the highly useful shareware, NPA for Windows is > out. This is the 11 Oct 97 version, with many new prefixes and area > codes since the July version. > Download it from http://www.pcconsultant.com/~robert/pcc > [TELECOM Digest Editor's Note: For newer readers or for old-timers > who do not remember much about him, Paul Cook has been a regular > participant here for several years. His scripts are trustworthy and > and quite useful. The best part is the price! PAT] I've been participating here from one address or another for over a decade, but if you're referring to the program NPA for Windows, its not mine. I'm just an enthusiastic user. It is shareware written and distributed by Robert Ricketts. Or perhaps by scripts PAT meant the text I submit to TELECOM Digest! Paul Cook * pcook@proctorinc.com ph: 425-881-7000 Proctor & Associates, Redmond, WA fax: 425-885-3282 http://www.proctorinc.com [TELECOM Digest Editor's Note: Sorry, I thought you wrote the script you were recommending. Apologies to the original author are extended. PAT] ------------------------------ Date: Mon, 03 Nov 1997 10:44:29 EST From: Rob Slade Subject: Book Review: "The VRML Sourcebook" by Ames/Nadeau/Moreland BKVRMLSB.RVW 970623 "The VRML 2.0 Sourcebook", Ames/Nadeau/Moreland, 1997, 0-471-16507-7, U$49.95/C$69.95 %A Andrea L. Ames andrea@sdsc.edu %A David R. Nadeau nadeau@sdsc.edu %A John L. Moreland moreland@sdsc.edu %C 22 Worchester Road, Rexdale, Ontario M9W 9Z9 %D 1997 %G 0-471-16507-7 %I Wiley %O U$49.95/C$69.95 416-236-4433 fax: 416-236-4448 800-263-1590 800-567-4797 %P 654 %T "The VRML 2.0 Sourcebook" The Virtual Reality Modeling Language, or VRML, is a "space description" language. It can be used as a standard for creating "3-space" artificial reality scenes. VRML also has the hypertext "linking" capability of HTML, the basis of the World Wide Web, and so, with an appropriate browser, can be used to create three dimensional extensions to the Web. This book provides a good introductory tutorial to the Virtual Reality Modeling Language for basic right up to expert usage. Within the limits of the printed page, the authors have provided a clear and solid introduction. Creating, rotating and moving simple and even complex shapes is given lucid and step-by-step explanations. With the inclusion of the CD-ROM the "sourcebook" becomes even more useful since it provides several VRML browsers that the reader can use, or at least try out. Even the simplest discussion of shapes and rotations can boggle the mind's eye when constrained to "dead trees": VRML is definitely a "hands-on" type of activity. This book will give you a firm grasp of the essentials and syntax of VRML. With the extensions to 2.0 the pace is much faster than it was in the original. Grasp of the concepts may require a bit more dedication, but the quality and clarity of the first edition is still much in evidence. copyright Robert M. Slade, 1996, 1997 BKVRMLSB.RVW 970623 ====================== Please note the Peterson story - http://www.freivald.org/~padgett/trial.htm Genesis 4:9/Proverbs 24: 11,12 - your choice ------------------------------ Date: Mon, 03 Nov 1997 10:49:23 -0600 From: Mark J. Cuccia Subject: Re: Switch Information Requested In TELECOM Digest, PB Schechter wrote: > Colorado is currently looking for ways to "conserve" numbers in the > 303 area code. One idea that has come up is the possibility of > turning Central Office Codes from NXXs to XXXs. This would add about > two million numbers, and is possible because Colorado is going to use > an overlay in the 303 area, so ten digits will need to be dialed for > all local calls. (Just to be perfectly clear: currently, a CO code > can't begin with 0 or 1 because those initial digits are used to > indicate operator and long distance calls, respectively. However, if > local calls are all prefaced with the area code, the initial digit of > a call to a number with a CO code beginning with 0 or 1 *will not be 0 > or 1.*) > Some people have claimed that this might "break" some switches > (particularly, outside of the North American Numbering Plan). It > seems to me that, once a switch sees that a call is going "somewhere > else" (i.e., to a different area code), it won't even look at the > remaining digits (or, if it does, it won't care what they are). > However, I am not a switch expert. > So, the request: (1) Does anyone know if there are any switches that > would complain about a CO code beginning with a 0 or a 1, even if they > dialed digit string does *not* begin with a 0 or a 1? (2) Does anyone > know how I can find this out? In an recent post regarding non-customer-dialable remote/rural locations (which can only be reached via a local telco or AT&T operator), the billing identification information is presently of the format 88X-XXX. Some of these locations have billing info of the form 88X-0xx-xxxx or 88X-1xx-xxxx, in addition to the form 88X-NXX-xxxx. _Even_if_ customers were able to 'dial' the billing code to call the remote/rural location, many NANP switches wouldn't be able to handle customer dialable strings of the format (1/0)+NXX-0XX-xxxx or (1/0)+NXX-1XX-xxxx. Other problems with 303-0XX and 303-1XX formats being used for central office codes for 'regular' customer-dialable numbers: There are other billing-codes, such as RAO-based calling-card numbers. An RAO is a "revenue-accounting-office". For about twenty years, there have been fourteen-digit calling-cards of the format NXX-0XX-xxxx+ PIN(nxxx) and NXX-1XX-xxxx+PIN(nxxx). The first three digits NXX are the digits of the RAO-code that the calling-card number is associated with. These are 'special-billing' calling cards. The NXX digits of the RAO are _NOT_ the area code. Offhand, I don't know where RAO #303 happens to be in the NANP. But if there are special-billing calling cards assigned off of RAO #303, they would be of the format 303-0XX-xxxx-nxxx and 303-1XX-xxxx-nxxx. If Colorado were to adopt 'regular' telephone numbers of the form 303-0XX-xxxx and 303-1XX-xxxx, those customers would want to be assigned line-number based calling cards, but they couldn't be, since the number-forat would conflict with 'special' calling cards and other special billing codes. ALSO, codes of the form NPA+0XX+ and NPA+1XX+ are used by operators and the automated network itself, for reaching other operators, for selecting specific trunks, for automated controls of portions of the network, for plant-testing, etc. There _are_ discussions in various "ATIS" and NANP telephone industry forums (such as the INC, OBF, NIIF, etc) as to how to expand the capacity of the NANP ten-digit number, or to increase the number of digits in a telephone number to more-than-ten. I don't think that any location would be able to adopt NPA-0XX/1XX format central-office-codes for regular numbers, "on its own". Before any such 'regular' numbers would be assigned, there would have to be various policies adopted at a higher level, such as Bellcore, NANPA (soon to be Lockheed-Martin), the ATIS forums, the NANC (North American Numbering Council), etc., to see if there are any conflicts in any possible proposals. As for when an originating switch sees that a call goes "somewhere else", the toll-switch of the long-distance carrier needs to do six-digit translation of the NPA-NXX to determine the route, and also the billing equipment presently determines the rate. The local originating telco's switch of the calling customer might not need to worry about the fourth/fifth/sixth digits, unless the call is 'nearby'. Also, most originating local telco switches _BLOCK_ customer dialing of a fourth-digit of 0/1 in a dialed string NXX-XXX-xxxx. _IF_ any NPA (area code) or SAC (Special Area Code) were to have regular customer-dialable central-office codes of the 0XX/1XX format, _EVERY_ switch in the NANP will have to be so noted that such would now exist. In some forms of equipment, this might only need to be a software update. But some types of equipment are _hard-coded_ to prohibit customer-dialing of a 0/1 in the 'D' digit. NWORLASKCG0 (BellSouth #1AESS Class-5 Local "Seabrook" 504-24x-) NWORLAIYCM1 (BellSouth-Mobility Hughes-GMH-2000 Cellular-MTSO NOL) NWORLAMA0GT (BellSouth DMS-100/200 fg-B/C/D Accss-Tandem "Main" 504+) NWORLAMA20T (BellSouth DMS-200 TOPS:Opr-Srvcs-Tandem "Main" 504+053+) NWORLAMA04T (AT&T #4ESS Class-2 Toll 060-T / 504-2T "Main" 504+) JCSNMSPS06T (AT&T #5ESS OSPS:Operator-Services-Tandem 601-0T 601+121) MARK_J._CUCCIA__PHONE/WRITE/WIRE/CABLE:__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: Chuck Tyrrell Subject: Sprint Tops in Customer Satisfaction Date: Mon, 3 Nov 1997 09:25:28 -0500 I found this press release interesting and thought that I would pass it along. None of the carriers met even a 70% approval rating from their customers, yet Sprint is referred to as a "premier" service provider. With scores such as these can't you just wait for them to provide local service as well? Chuck Tyrrell ---------------------- Monday November 3 7:59 AM EST Company Press Release Sprint Tops in Customer Satisfaction for Fourth Straight Year, Yankee Group Survey Finds BOSTON, Nov. 3 /PRNewswire/ -- Consumers who use Sprint as their long-distance telephone company say they are happier with the service they receive than their counterparts who use either AT&T or MCI. That's the conclusion of a new survey from the Yankee Group, a Boston-based market research firm. According to the Yankee Group's recently completed 1997 Technologically Advanced Family (TAF) survey, Sprint residential customers gave the company the highest ratings for quality of service in eight key areas. In fact, 1997 marked the fourth consecutive year in which Sprint led the long-distance market in quality of service, and the third year in which it was ranked first in all eight of the service categories measured by the Yankee Group. ``Sprint has done an outstanding job in maintaining its position as a premier service provider to its residential customers,'' says Brian Adamik, vice president of consumer communications research at the Yankee Group. ``In addition to leading its rivals in the long-distance market, Sprint's record for customer service will help the company compete with the Baby Bells for customers in the local exchange market,'' he adds. The 1997 TAF survey asked over 1,900 consumers to evaluate various aspects of their local and long-distance telephone company's service. The long-distance portion of the survey produced the following results: Quality of Service Sprint AT&T MCI (Percentage of customers answering excellent or good) Professional, Courteous, Knowledgeable Personnel 62.3 60.5 53.9 Accurate and Easy-to-Understand Bills 66.0 61.1 53.8 Timely Resolution of Problems 56.1 54.2 43.5 Quick Access to Customer Service 55.9 52.7 44.0 Value for the Money 62.6 45.5 45.4 Provides High-Quality Transmission 67.3 60.3 54.1 Trustworthiness 58.6 56.4 42.2 Deserving of My Loyalty 57.2 53.9 35.3 Working in conjunction with Market Facts, Inc., the world's leading supplier of mail panel consumer research, the Yankee Group has constantly refined and upgraded the TAF survey over its 12-year history. Unlike other consumer studies now flooding the communications and computing industries, TAF offers marketers two critical advantages: a proven scheme for consumer segmentation and a broader array of products and services covered. Since 1986, the Yankee Group has used the TAF survey to measure consumer interest, attitudes, and demand regarding a broad assortment of communications products and services. These range from basic communications services such as local and long-distance telephony to advanced technologies in personal computing and home entertainment. The 1997 survey's results were drawn from a 32-page questionnaire mailed to a representative sample of U.S. and Canadian households. In addition to its North American coverage, TAF has recently been expanded to include separate survey's of France, Germany, and the United Kingdom. SOURCE The Yankee Group ------------------------------ Date: Tue, 04 Nov 1997 09:21:29 -0500 From: S Hayman Reply-To: srhayman@sciborg.uwaterloo.ca Organization: University of Waterloo Subject: canadian area codes Hello: I was browsing through your site, but was unable to find the information I was seeking. Could you please help me out by letting me know which region in Canada was first served by an area code without a middle digit of 0 or 1? Sorry for any inconvenience, but I hope you can help me out. Thanks, Steve ------------------------------ End of TELECOM Digest V17 #301 ******************************