==Phrack Inc.== Volume Two, Issue 24, File 1 of 13 Phrack Inc. Newsletter Issue XXIV Index ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ February 25, 1989 Welcome to Phrack Inc. Issue 24. We're happy to be able to say that we've been keeping with our proposed release dates recently as opposed to our problems with delays in the past. A little clearing up needs to be done briefly. We have received questions about the volume number being only 2 when, year-wise, it should be at about 4. In our opinion, a volume consists of 12 issues, ideally having 1 issue per month. Unfortunately, we have not been able, in the past, to keep up the pace. If you're looking forward to a volume change, though, watch for issue 25 to lead into Volume 3 of Phrack Inc. A brief announcement about SummerCon '89 appears in Phrack World News XXIV and more details will be released as they develop. As always, we ask that anyone with network access drop us a line to either our Bitnet accounts or our Internet addresses (see signoff). In this issue, we feature the conclusion of the Future Transcendent Saga as well as a supplement file of sorts to it called Advanced Bitnet Procedures submitted by VAXBusters International. We hope you enjoy it! Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU _______________________________________________________________________________ Table of Contents: 1. Phrack Inc. XXIV Index by Taran King and Knight Lightning 2. Phrack Pro-Phile XXIV Featuring Chanda Leir by Taran King 3. Limbo To Infinity; Chapter Three of FTSaga by Knight Lightning 4. Frontiers; Chapter Four of FTSaga by Knight Lightning 5. Control Office Administration Of Enhanced 911 Service by The Eavesdropper 6. Glossary Terminology For Enhanced 911 Service by The Eavesdropper 7. Advanced Bitnet Procedures by VAXBusters International 8. Special Area Codes by >Unknown User< 9. Lifting Ma Bell's Cloak Of Secrecy by VaxCat 10. Network Progression by Dedicated Link 11-13. Phrack World News XXIV by Knight Lightning _______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 2 of 13 ==Phrack Pro-Phile XXIV== Created and Written by Taran King Done on February 3, 1989 Welcome to Phrack Pro-Phile XXII. Phrack Pro-Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This issue, I present one of the more rare sights in the world of phreaking and hacking...a female! She was vaguely active and had a few contacts with people that were largely involved with the community... Chanda Leir ~~~~~~~~~~~ Handle: Chanda Leir Call Her: Karen Past Handles: None Handle Origin: An aunt of hers as a child wanted to use this name is she ever became famous. Date Of Birth: May 8, 1970 Current Age: Almost 19 Height: 5' 6" Weight: 125 lbs. (providing Freshman 15 hasn't yet hit) Eye Color: Green/Grey Hair Color: Blond Computers: Her father is a real estate broker, so she began on a TI 700 terminal (an MLS Terminal)... just a modem and a keyboard and a scroll of PAPER)... then it was dad's business computer-- the KAYPRO II... Now she uses the Macs and the Sun systems and the IBM RT's located at CMU. ------------------------------------------------------------------------------- Karen started using BBSes in the D.C. area in 1983 (at the ripe age of 13). A guy by the name of Hack-Man (she supposes this was the "original" H-M) was running a board off of the dead side of the local 678 loop. Her introduction to phone "stuff" began when she called the "board" one day and found instead 30 people on the line instead of a carrier. She was dumbfounded, and being female, there were 30 guys on the conference ready and willing to provide her with information as to origins of loops, conferences, boxing, etc. Scott (Hack-Man) later filled her in on the rest, gave her more numbers and such and that's where it all began. The memorable phreakers or hackers that Karen has met include Cheshire Cat, Tuc, Bioc Agent 003 and anyone else who was at the TAP meeting during Thanksgiving of 1984. She gained her experience by asking a LOT of questions to a lot of hard-up guys who were willing to give her all kinds of info since she was a girl. She attributes her information mostly to just taking in and remembering all of the information that people gave her. The two boards that Karen listed as memorable were both in Falls Church, VA. which were Mobius Strip and Xevious II. Currently she's a freshman at Carnegie Mellon University in Pittsburgh (or as she likes to call it, COMPUTER U.). Her major is probably "Policy & Management." Her major accomplishment is that she was probably the youngest girl ever to attend a TAP meeting (at the age of 14) and probably one of the only people to attend one with Mom, Dad, and Aunt Linda (how embarrassing). One of the reasons she quit the phreak/hack world was because of a visit from the Secret Service in February 1985... although they didn't really come for her... A "friend" wanted for credit card fraud called her while his line was hooked to a pin register. The same weekend he called Karen, was Inauguration Weekend and she and her brother called the 456 (White House) loop something like 21 times in the 4-day weekend period... In any case the SS wanted to catch Eric and when her number showed up in two places, they decided to investigate. Freaked out her parents! The real reason she quit the phreak/hack world was because she transferred high schools in 1985 and became one of the "popular" kids and gained a social life, thus losing time and interest for the computer. ------------------------------------------------------------------------------- Chanda Lier's Interests Include: MUSIC... specifically harDCore... (that would be punk rock from Washington, DC). Most of her friends are or were in DC bands... The Untouchables, Teen Idles, Minor Threat, Youth Brigade (DC), Grey Matter, Government Issue, etc. HORROR... novels, movies, comics.... Clive Barker, Arcane Comix (of which her friend Steve is publisher of), Peter Straub, Dean Koontz, Whitely Streiber etc... that whole genre... And Flannery O'Connor rules... Her most memorable experiences include the following: Her parents used to "make" her start conferences for them whenever it was a relative's birthday. They would get the whole family on the line and chat and stuff. Everyone thought it was really cool.... Other fun times were when her dad would pull out his DoD (Department of Defense) phonebook and they would hack around for modem lines.... Tuc coming to her grandmother's house in April 1985 and then going to see "Desperately Seeking Susan"... Some People to Mention: "I guess, just Taran King, for this interview, and Knight Lightning...both of whom contacted me here at CMU.... and TUC... and ...?" ------------------------------------------------------------------------------- And of course...that regular closing to the Phrack Pro-Phile... Are most of the phreaks and hackers that you've met computer geeks? "YES... no doubt." Thanks for your time, Karen. Taran King ==Phrack Inc.== Volume Two, Issue 24, File 3 of 13 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Limbo To Infinity <> <> ~~~~~~~~~~~~~~~~~ <> <> Chapter Three of The Future Transcendent Saga <> <> <> <> Traversing The Barriers For Gateway Communication <> <> <> <> Presented by Knight Lightning <> <> February 11, 1989 <> <> <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Beyond Bitnet lies the other wide area networks. We will discuss more about those networks in chapter four. Right now lets learn how to communicate with those other realms. _______________________________________________________________________________ Mailing To Other Networks - Gateway Communications ~~~~~~~~~~~~~~~~~~~~~~~~~ Bitnet, as you already know, is not the only computer network in the world. What you might be surprised to find out, however, is that when you have access to Bitnet you also have access to many other networks as well. Unfortunately, the methods for communicating with people in these other networks are not as simple as the ones described earlier. Bitnet's links to other networks give you access to people and services you could not contact otherwise (or at least without great expense). This alone should make learning a bit about them worthwhile. In chapter one of this series, I showed you how some Bitnet nodenames can be broken down into state abbreviations. To go a step further, try and think of Bitnet as a country and the links between the Bitnet nodes as highways. Another network (or country in this example) is connected to our highway system at one point, which is called a "gateway." These borders do not let interactive messages or files through; only mail is allowed past the gateway. The people in these other networks have addresses just like yours, but you will need to specify something extra in order to get mail to them. A userid@node address is not enough, because that does not tell the Bitnet mail software what network that node is in. Therefore, we can extend the network address with a code that identifies the destination network. In this example, the destination network is ARPAnet (a network I'm sure you have heard much about), the code for which is ARPA. TARAN@MSP-BBS.ARPA +---- +------ +--- | | | | | +-------------------- the network | | | +---------------------------- the node | +---------------------------------- the userid That is about as simple as an address from another network gets. Generally they are much more complex. Because of the variety of networks there can be no example which will show you what a "typical" address might be. However, you should not have to let it worry you too much. If someone tells you that his network address is C483307@UMCVMB.MISSOURI.EDU, just use it like that with your mail software. As long as you understand that the mail is going to another network and that the transit time may be longer than usual (although in many cases I have found that mail going to EDU addresses is delivered much faster than Bitnet mail) you should not have many problems. More On Gateways ~~~~~~~~~~~~~~~~ I introduced the gateways in the previous section, but didn't get into too much detail. This is because the subject can get more than a little complex at times. Actually, understanding gateways isn't difficult at all, but interpreting network addresses that use them can be. In the previous example, an address for someone in another network looked like this: TARAN@MSP-BBS.ARPA The ".ARPA" in the address tells your networking software that your letter should go to someone in another network. What you might not realize is that your networking software "knows" that the address for the gateway to ARPA may be at, say INTERBIT. It might extend the address to look something like this: TARAN%MSP-BBS.ARPA@INTERBIT +---- +------ +--- +------- | | | | | | | +--------------- the node of the gateway | | | | | +-------------------- the network | | | +---------------------------- the node | +---------------------------------- the userid The gateway is a server machine (userid@node) that transfers files between the two networks. In this case, it is ARPA@INTERBIT. Note that the "%" replaces the "@" from the previous example. This is because Bitnet networking software cannot handle addresses with more than one AT sign (@). When your mail gets to the gateway, the "@INTERBIT" would be stripped off, and the "%" would be turned back into a "@". Ok, so now you are asking, "If this is so automatic, why do you need to know this?" In many cases your networking software is not smart enough to know that the gateway for SCONNET is at STLMOVM. If this is the case, you have to type out the whole address with all of the interesting special characters. For example, sometimes, you may have to change the addresses around somewhat. Let's say I'm talking to Lex Luthor one day and he tells me his address is "lex@plover.COM". I have found that an address like "lex@plover.COM" would actually be mailed to as "plover!lex@RUTGERS.EDU". Now this is just a specific example of how it works from my particular system and other systems (not to mention networks) will work differently (this is a guide for people using Bitnet). The COM (Commercial) addresses are not recognized by the mailer at UMCVMB and so I have to route them through Rutgers University. In chapter four, I will discuss some of the other networks that are interconnected. In many cases, a gateway to a network may be in another network. In this example, we are sending mail to RED at node KNIGHT in HDENNET. The gateway to the network is in, say, ARPAnet. Our networking software is smart enough to know where ARPA gateway is, so the address might look something like this: RED%KNIGHT.HDENNET@SRI-NIC.ARPA +-- +----- +------ +------ +--- | | | | | | | | | +----- the network of the gateway | | | | | | | +------------- the node of the gateway | | | | | +--------------------- the network | | | +---------------------------- the node | +-------------------------------- the userid As you can see, these addresses can get pretty long and difficult to type. Perhaps the only consolation is that your address probably looks just as bad to the people in the destination network. Foundations Abound ~~~~~~~~~~~~~~~~~~ Just as there are servers and services in Bitnet, there are similar counterparts in the other networks as well. There are many electronic digests and servers that are similar to Bitnet servers available on several of the other networks. _______________________________________________________________________________ Gateways To Non-Standard Networks - Intermail ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Intermail is perhaps the most interesting exception to standard gateways. It's better to just show you what I mean rather than try to really technically describe the process. With Intermail, you can access networks you probably never thought were accessible. I have included the instructions for using the Intermail system for transmitting computer mail between users in the MCI-Mail system, the GTE Telemail system, the Compmail/Dialcom 164 system, and the NFS-Mail/Dialcom 157 system to the ARPA-Mail system. The Intermail system may be used in either direction. Mail to be sent to MCI Mail, GTE Telemail, Compmail, or NSF-Mail is sent to the "Intermail" mailbox on the local mail system. The Intermail system operates by having a program service mailboxes in both the local and the destination mail systems. When the right information is supplied at the beginning of a message, the program forwards those messages into the other mail system. In order for a message to be delivered to a mailbox in another mail system, forwarding information must be included at the beginning of the text of each message. This forwarding information tells the mail forwarding program which mail system to forward the message to, and which mailboxes to send it to. This information is in the form: Forward: To: The syntax allowed on the "To:" line is that of the system being forwarded into. In ARPA-Mail it is also possible to send to a list of CC recipients in any of the mail gateway systems. See the examples for further details. In either direction, the local Subject field of the message to Intermail is used as the Subject field of the message delivered in the other mail system. Sending To Non-Standard Networks From Bitnet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this direction, the Internet user must first send mail to the Intermail mailbox on the ARPA-Internet. The address of "Intermail" is "INTERMAIL@ISI.EDU". Next, the Mailbox forwarding information must be added at the beginning of the text of each message. The names of the mailboxes are MCI-MAIL, TELEMAIL (for GTE Telemail), COMPMAIL, and NSF-MAIL. This information is in the form: Forward: To: Please Note: Although CompuServe (CIS), Telex, and FAX are accessible from MCI-Mail, the Intermail gateway does not support these services. However, there is a Bitnet-CompuServe gateway, but that will be discussed in the next section of this file. Sending To Bitnet From Non-Standard Networks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Supposing that you have an account on MCI-Mail, GTE Telemail, Compmail, or NSF-Mail and you would like to mail to someone on Bitnet, you would direct your mail to one of the following addresses; "INTERMAIL" (actually MCI-ID "107-8239") in MCI-Mail, "INTERMAIL/USCISI" in GTE Telemail, "164:CMP00817" in Compmail/Dialcom 164, and "157:NSF153" in NSF-Mail Once you have done this, you actually type the following as the first two lines in the mail: Forward: ARPA To: KNIGHT%MSPVMA.BITNET@CUNYVM.CUNY.EDU In this example, KNIGHT is the userid and MSPVMA is the Bitnet node. CUNYVM.CUNY.EDU is the Internet gateway to ARPAnet. It's really just that simple. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In case of questions or problems using Intermail, please send a message to Intermail-Request@ISI.EDU. _______________________________________________________________________________ CompuServe ~~~~~~~~~~ The gateway is not yet live as of this writing. Testing on it has been delayed somewhat because of high-priority projects inside CompuServe. However, it might be a safe bet that by the time you read this that the gateway will be complete. The specific mechanism is that the gateway machine, 3B2/400 named Loquat, believes that it has a UUCP neighbor "compuserve" which polls it. In reality, the UUCP connection is a lie all around, but the gateway starts up on an hourly basis, pokes through the UUCP queue, finds mail aimed at CompuServe, and creates script language on the fly suitable for a utility called Xcomm 2.2 to call CompuServe, download any waiting mail, and upload any queued mail. Appropriate header hacking is done so that CompuServe looks like just another RFC-compliant entity on the Internet, and the Internet looks like yet another gatewayed system from the perspective of the CompuServe subscriber - a very minor modification to the usual syntax used in their mailer is needed, but this project has provided the impetus for them to generalize the mechanism, something they had apparently not needed before. So that's where it stands. Loquat speaks with machines at Ohio State. At the moment, there is a problem preventing mail passage except between CompuServe and Ohio State, while they finish development and testing. Also, part of the header hacking done is to make CompuServe IDs look right on the Internet - the usual 7xxxx,yyy is a problem due to the presence of the ",". _______________________________________________________________________________ Easynet ~~~~~~~ A mail gateway between Easynet and the UUCP network and DARPA Internet (including CSNET) is provided by the Western Research Laboratory in Palo Alto, California. Hopefully this service will provide improved communications between the DEC community and the Usenet and Internet communities. Mailing From A Bitnet Site To An Easynet Node ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To mail a message from an Internet site to an Easynet node (say MSPVAX), you type: To: user%mspvax.dec.com@decwrl.dec.com A few other forms are still accepted for backward compatibility, but their use is discouraged and they will not be described here. Mailing From Easynet To Bitnet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For people on Easynet who would like to mail to people on Bitnet the following information may be of interest. The gateway supports connection to Bitnet using a pseudo-domain syntax. These addresses are translated by the gateway to the proper form to address the gateway into Bitnet. To address users in Bitnet you type: To: DECWRL::"user@host.bitnet" (Example: To: DECWRL::KNIGHT@MSPVAX.BITNET) _______________________________________________________________________________ Mailnet ~~~~~~~ The Bitnet-Mailnet Gateway no longer exists. EDUCOM's Mailnet Service was discontinued after June 30, 1987 in agreement with MIT. _______________________________________________________________________________ DASnet ~~~~~~ DASnet is one of the networks that is connected to AppleLink. Sending to DASnet from Bitnet: 1. In the "TO" field, enter the DASnet gateway address: XB.DAS@STANFORD.BITNET 2. In the "SUBJECT" field, enter the DASnet user id (such as [1234AA]joe) Example (0756AA is the DASnet address and randy is the user on that system): To: XB.DAS@STANFORD.BITNET Subject: [0756AA]randy 3. If you type a "!" after the address in the subject field, you can insert comments, but the subject line must be limited to 29 characters. Example; Subject: [0756AA]randy!Networks are cool Sending to Bitnet from DASnet 1. In the "TO" field, enter the BITNET address followed by "@dasnet" 2. Use the "SUBJECT" field for comments. Example: To: knight@umcvmb.bitnet@dasnet#MSubject: Gateways Don't be confused, there are two @s and a at the end. _______________________________________________________________________________ Gateways Between Bitnet And Other Networks Not Previously Detailed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________________________________ | | | | | "u" = UserId | "h" = Host (Node) | "d" = Node (Host) | |______________|___________________|___________________| To: CSNET Phonenet @.csnet To: JANET (Domains: U: uk) %.U@ac.uk To: EAN (Domains: E: cdn, dfn, etc.) @.E To: COSAC /@france.csnet To: Xerox Internet (Domains: R: A registry) .R@xerox.com To: DEC's Easynet <*Detailed Earlier*> %.dec.com@decwrl.dec.com To: IBM's VNET @vnet To: ACSNET (Domains: A: oz.au) %.A@ To: UUCP h1!h2!!@psuvax1 To: JUNET (Domains: J: junet) %.J@csnet-relay.csnet To: JANET %U.@ac.uk - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To: BITNET From ARPA Internet %.bitnet@cunyvm.cuny.edu CSNET Phonenet %.bitnet@relay.cs.net JANET %@uk.ac.rl.earn EAN @.bitnet COSAC adi/%.bitnet@relay.cs.net ACSNET %.bitnet@munnari.oz UUCP psuvax1!.bitnet! JUNET @.bitnet _______________________________________________________________________________ Conclusion ~~~~~~~~~~ Now that you understand how to mail to the other networks by making use of the gateways, we will begin looking at the other networks themselves. As my greatest area of expertise is Bitnet, I will cover the other networks in less detail. If they interest you, I'm sure you will find a way to learn more about them. So read Chapter Four of The Future Transcendent Saga -- Frontiers. :Knight Lightning _______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 4 of 13 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Frontiers <> <> ~~~~~~~~~ <> <> Chapter Four of The Future Transcendent Saga <> <> <> <> Beyond Bitnet Lies Infinity <> <> <> <> Presented by Knight Lightning <> <> February 12, 1989 <> <> <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Welcome to the final chapter of The Future Transcendent Saga... or is it? Can there ever really be a final chapter to the future? In any case, I have collected information on some of the various other networks that you may comes across through your use of Bitnet. These listings are more of a summary than a detail guide (like Utopia was for Bitnet). However, I think you'll make good use of the information presented here. Much of the information in this file is based on examination of research conducted in July, 1987. Any errors due to the advancement in technology and the difference in time are apologized for. The networks indexed in this file include the government agency networks ARPANET, MILNET, MFENET, and NSFnet; and the user-formed networks CSNET, HEANET, SPAN, TEXNET, UUCP, and USENET. This file is not intended to be a hackers guide, but merely a directory of some of the networks. One last thing to mention... the major top level domains on the Internet are: .EDU Educational Institutions .COM Commercial .GOV Government .MIL Military .ORG Miscellaneous Orgainizations (that don't fit elsewhere) _______________________________________________________________________________ GOVERNMENT AGENCY NETWORKS ~~~~~~~~~~~~~~~~~~~~~~~~~~ ARPANET and MILNET In 1969 the Defense Advanced Research Projects Agency (DARPA) began a research program to advance computer networking. The experimental packet-switched network that emerged was called ARPANET, and it allowed computers of different types to communicate efficiently. Using ARPANET technology, the Defense Data Network (DDN) was created in 1982 to encompass the existing ARPANET and other Department of Defense (DoD) computer networks. The DDN uses the DoD Internet Protocol Suite, including TCP/IP (Transmission Control Protocol/Internet Protocol) and associated application protocols. A splitting of the ARPANET was begun in 1983 and completed in 1984. The result was two networks, an experimental research and development network called ARPANET, and a non-classified operational military network called MILNET. Gateways interconnect the two networks. The backbones of each of the networks consist of Packet Switched Nodes (PSNs), most of which are connected with 56 Kb terrestrial lines. As of January 1987, the ARPANET had 46 PSNs, and MILNET had 117 PSNs in the U.S. and 33 in Europe and the Pacific. While ARPANET and MILNET make up part of the DDN, the DDN and other networks works which share the same protocols make up the ARPA Internet. CSNET X25net, which uses the TCP/IP protocols interfaced to the public X.25 network, is an example of a network which is part of the ARPA Internet and is not a part of the DDN. ________________________________________ | +--------------+ | | | CSNET X25net | | | +--------------+ | | +---------------+ | | | DDN | | | | +---------+ | | | | | Arpanet | | | | | +---------+ | | | | | | | | +---------+ | | | | | Milnet | | | | | +---------+ | | | +---------------+ ARPA Internet | |________________________________________| Policy, access control and funding for the ARPANET are provided by DARPA's Information Processing Techniques Office (IPTO). ARPANET and MILNET operation and management are provided by the Defense Communications Agency's DDN Program Management Office (DDN PMO). Use of the ARPANET is limited to users engaged in experimental research for the U.S. government, or government-sponsored research at universities. Because it is not meant to compete with commercial networks, it is not intended for operational communication needs or use by the general public. Services available on ARPANET and MILNET include remote login, file transfer, mail, time, and date. Mail addressing on both of the networks is of the form user@domain, where domain refers to a full qualified domain name composed of a string of one or more subdomains separated by a period, ending with a top-level domain. Examples of top-level domains: edu, com, gov, mil, net, org, jp, au, uk. Examples of fully qualified domain names: kentarus.cc.utexas.edu, relay.cs.net, icot.jp. The DDN funds a Network Information Center (NIC), located at SRI International in Menlo Park, California, which provides user services to DDN users via electronic mail (NIC@SRI-NIC.ARPA), telephone (800-235-3155) and U.S. mail: DDN Network Information Center, SRI International, Room EJ291, 333 Ravenswood Avenue, Menlo Park, CA 94025. The telephone service is available Monday through Friday, 7a.m to 4p.m., Pacific time. Much information is also available on-line on SRI-NIC.ARPA, via telnet or anonymous ftp (login "anonymous", password "guest"). The file NETINFO:NETINFO-INDEX.TXT contains an index of these on-line files. _______________________________________________________________________________ MFENET MFEnet is the Department of Energy's (DOE) magnetic fusion energy research network. It was established in the mid-1970's to support access to the MFE Cray 1 supercomputer at the Lawrence Livermore National Laboratory. The network uses 56-kbs satellite links, and is designed to provide terminal access to the Cray time-sharing system (CTSS), also developed at the Lawrence Livermore Laboratory. The network currently supports access to Cray 1, Cray X-MP/2, Cray 2, and Cyber 205 supercomputers. The network uses special-purpose networking software developed at Livermore, and, in addition to terminal access, provides file transfer, remote output queuing, and electronic mail, and includes some specialized application procedures supporting interactive graphics terminals and local personal computer (PC)-based editing. Access to the network is in general restricted to DOE-funded researchers. A couple of years ago, the network was expanded to include the DOE-funded supercomputer at Florida State University. MFEnet is funded by DOE and managed by Livermore. MFEnet has been successful in supporting DOE supercomputer users. However, the specialized nature of the communications protocols is now creating difficulties for researchers who need advanced graphics workstations that use the UNIX BSD 4.2 operating system and the TCP-IP protocols on LAN's. For these and other reasons, DOE is examining how best to migrate MFEnet to the TCP-IP, and later to the OSI, protocols. The combination of the CTSS operating system and the MFEnet protocols creates an effective interactive computing environment for researchers using Cray supercomputers. For this reason, two of the new NSF national supercomputer centers -- San Diego (SDSC) and Illinois -- have chosen the CTSS operating system. In SDSC's case, the MFENET protocols have also been chosen to support the SDSC Consortium network. In Illinois case, a project to implement the TCP-IP protocols for the CTSS operating system has been funded by the NSFnet program, and these developments will be shared with SDSC (and with DOE) to provide a migration path for the SDSC Consortium network. Mail can be sent to people on MFEnet by using this format; user%site.MFENET@NMFEDD.ARPA _______________________________________________________________________________ NSFNET NSFnet began in 1986 as a communications network to facilitate access to NSF-funded national supercomputer centers. It is evolving into a general purpose internet for research and scientific information exchange. The network has a three-level component structure comprised of a backbone, several autonomously administered wide-area networks, and campus networks. The backbone includes the following supercomputer centers: - National Center for Supercomputing Applications, University of Illinois, Urbana (UIUC) - Cornell National Supercomputer Facility, Cornell University (Cornell) - John von Neumann National Supercomputer Center, Princeton, New Jersey (JVNC) - San Diego Supercomputer Center, University of California, San Diego (SDSC) - Pittsburgh Supercomputer Center (Westinghouse Electric Corp, Carnegie-Mellon University, University of Pittsburgh) - Scientific Computing Division of the National Center for Atmospheric Research, Boulder, Colorado (NCAR) Upper layer protocols in use on the NSFnet backbone are the TCP/IP protocols. The backbone became operational in July of 1986. It was composed of seven 56 kps links between six IP gateways. These gateways are LSI 11/73 systems. An upgrade to T1 links (1.544 Mps) was established in the latter part of 1987. There are plans to adopt the OSI networking protocols as the software becomes available. NSF-funded component networks include: BARRNET - California's Bay Area Regional Research Network MERIT - Michigan Educational Research Network MIDNET - Midwest Network NORTHWESTNET - Northwestern states NYSERNET - New York State Educational and Research Network SESQUINET - Texas Sesquicentennial Network SURANET - Southeastern Universities Research Association Network WESTNET - Southwestern states JVNCNET - consortium network of JVNC SDSCNET - consortium network of SDSC PSCAAnet - consortium network of the Pittsburgh Supercomputer Center Some of the component networks preceded NSFnet, and some of them have just recently been established. Each of the component networks is connected to the backbone. Information about the status of any NSFnet component network is available from the NSFnet Network Service Center (NNSC). Monthly reports on the status of the backbone and component networks are also available on-line through the CSNET Info-Server. Send a message to info-server@sh.cs.net with the following message body: REQUEST: NSFNET TOPIC: NSFNET-HELP REQUEST:END These reports may also be retrieved by anonymous ftp (login "anonymous", password "guest") from sh.cs.net, in the directory "nsfnet." [FTP stands for File Transfer Protocol] Other autonomous networks connected to the NSFnet backbone include ARPANET, BITNET, CSNET, and USAN (the University Satellite Network of the National Center for Atmospheric Research). Interesting projects associated with NSFnet include implementation of the gated routing daemon which handles the RIP, EGP and HELLO routing protocols and runs on 4.3BSD, Ultrix TM, GOULD UTX/32 TM, SunOS and VMS TM (Cornell University Theory Center); implementation of TCP/IP for the CTSS operating system supporting TELNET and FTP (University of Illinois); and a satellite experiment providing 56 kps links between distant ethernets using Vitalink technology (NCAR). Management of the NSFnet is in an interim form with duties shared among The University of Illinois, Cornell University, the University of Southern California Information Sciences Institute, and University Corporation for Atmospheric Research. The NSFnet project is administered by the Division of Network and Communications Research and Infrastructure, which is part of the Computer and Information Science and Engineering Directorate at NSF. Further information is available from the NSFnet Network Service Center (NNSC), BBN Laboratories Inc., 10 Moulton Street, Cambridge, MA 02238. Assistance can also be obtained by electronic mail to nnsc@nnsc.nsf.net, or by calling 617-497-3400. The NNSC is run by Bolt, Beranek and Newman, and is an NSF-funded project of the University Corporation for Atmospheric Research. _______________________________________________________________________________ USER-FORMED NETWORKS ~~~~~~~~~~~~~~~~~~~~ CSNET In 1980 a proposal was presented to the National Science Foundation to fund a computer science research network to link any university, commercial or government organizations involved in research or advanced development in computer science and computer engineering. NSF provided funding for the period for 1981 to 1985, and CSNET was established. This single logical network today connects approximately 200 computers on three physical networks. These component physical networks are Phonenet, X25net and a subset of the ARPANET. Phonenet is a store-and-forward network using MMDF software over public telephone lines to provide electronic mail service. X25net utilizes the public X.25 packet switched network Telenet, interfaced with TCP/IP, to provide electronic mail, file transfer and remote login. Some ARPANET hosts are also members of CSNET. The computers linked by CSNET are in the U.S., Europe, Canada, Israel, Korea and Japan. Addressing in CSNET is in the ARPA Internet domain style. In 1981 a contract was arranged with Bolt, Beranek and Newman, Inc. to provide information, user and technical services for CSNET, and the CSNET Coordination and Information Center (CIC) was established. The CIC handles the daily management of the network, and oversight is provided by the CSNET Executive Committee. The network is supported by membership fees. The CIC maintains a User Name Server database, which is accessible through the ns command on CSNET hosts running appropriate software, or by telnet to the CSNET service host, sh.cs.net (login "ns", no password required). There is also much information available via anonymous ftp to sh.cs.net (login "anonymous", password "guest"), particularly in the directory "info." The Info Server also provides a means for retrieving this information. To utilize the Info Server, send mail to infoserver@sh.cs.net with the following lines in the message body: REQUEST: INFO TOPIC: HELP REQUEST: END The on-line information includes software, policy documents, information on other networks, site lists and mailing list archives. CSNET Foreign Affiliates and their gateways are: CDNNET -- Canadian Academic Network, University of British Columbia. SDN -- System Development Network (SDN) is an R&D computer network, consisting of computers of R&D communities in Republic of Korea, with a gateway at KAIST, Korea Advanced Institute of Science and Technology, Seoul. It has mail connection to CSNET/Internet, USENET/EUNET/UUCP Net and Pacific countries like Australia, Indonesia, Hong Kong, Singapore and Japan. SUNET -- Swedish University Network, Chambers University of Technology, Gothenburg. CHUNET -- Swiss University Network, ETH-Zentrum, Zurich. Inria -- French University Network, Institute National de Recherce en Informatique, Rocquencourt. DFN -- Deutches Forschungsnetz, GWD-Gesellschaft fuer Mathematick und Datenvararbiten, Schloss Birlinghoven, St. Augustin. JUNET -- Japanese University Network, University of Tokyo. Finnish University Network, Helsinki University, Helsinki. AC.UK -- Academic Community, United Kingdom, University College, London. ACSNET -- A UUCP-based academic network in Australia, University of Melbourne. New Zealand Academic Network, Waikato University, Hamilton. Israeli Academic Network, Hebrew University of Jerusalem. For more information contact CSNET CIC, BBN Laboratories Inc., 10 Moulton Street, Cambridge, MA 02238, or send electronic mail to cic@sh.cs.net (cic@csnet-sh.arpa). A 24-hour hotline is also available, (617) 497-2777. _______________________________________________________________________________ HEANET HEAnet is a network linking the Universities and National Institutes for Higher Education in the Republic of Ireland. The following institutions belong to HEANET: NIHED: National Institute for Higher Education, Dublin NIHEL: National Institute for Higher Education, Limerick MAY: St. Patrick's College, Maynooth TCD: Trinity College, Dublin UCC: University College, Cork UCD: University College, Dublin UCG: University College, Galway The abbreviations on the left are used to form the network addresses for the hosts belonging to each institution. Addresses use the form: host.institution.IE (for example VAX2.NIHED.IE) HEANET is connected to EARN/Bitnet/Netnorth by a gateway at University College, Dublin. Mail for HEANET should be sent as a BSMTP "job" to MAILER at IRLEARN. _______________________________________________________________________________ SPANet The Space Physics Analysis Network (SPAN) became operational in 1981, and was the result of a pilot project at Marshall Space Flight Center funded by NASA (Space Plasma Physics Branch, Office of Space Science). The network is a mission-independent data system testbed, intended to address problems of exchanging data (raw and processed), analysis software, graphic images and correspondence between researchers in several disciplines, including Solar-Terrestrial, Interplanetary and Planetary Physics, Astrophysics, Atmospherics, Oceans, Climate and Earth Science. A perception that multidisciplinary correlative research in solar-terrestrial physics would increase in the 1980's, that standards were lacking in scientific databases, and that support was required for the display of device independent graphic images, all motivated the establishment of SPAN. SPAN has therefore developed to facilitate space data analysis and address significant unresolved problems of scientific data exchange and correlation. The Data Systems Users Working Group, formed in 1980, provides guidance and policy recommendations to SPAN. Daily operation of the network is performed by a network and project manager, a project scientist, routing center managers, and managers at the local nodes. SPAN nodes communicate using a variety of transmission media (fiber optics, coax, leased telephone lines) and lower layer protocols (ethernet, X.25, DDCMP), and nearly all SPAN hosts use the DECnetTM upper layer protocols. There are plans to migrate to the emerging OSI protocols as software becomes available. Currently SPAN connects over 1200 computers throughout the United States, Europe, Canada, and Japan (leading to all of the hacker related trouble on the network, such as the Mathias Speer incident). The network backbone in the United States consists of redundant 56 kps links between 5 DECnet routing centers: 1. NASA's Johnson Space Center (Houston, Texas) 2. NASA and Cal Tech's Jet Propulsion Laboratory (Pasadena, California) 3. NASA's Marshall Space Flight Center (Huntsville, Alabama) 4. NASA's Goddard Space Flight Center (Greenbelt, Maryland) 5. NASA's Ames Research Center (Moffett Field, California) Tail circuits connect SPAN member institutions to the closest routing center, in most cases with leased lines at a minimum of 9.6 kps. SPAN is gatewayed to CSNET, ARPANET, BITNET, GTE Telenet, JANET and the NASA Packet Switched System (NPSS). SPAN is joined to TEXNET, HEPnet and other DECnetTM wide area networks. Services available to SPAN nodes include electronic mail, remote file transfer and remote login. Additional information is available from the SPAN Network Information Center (SPAN-NIC) located at the National Space Science Data Center, NASA Goddard Space Flight Center, Greenbelt, Maryland 20771. Assistance is also available by electronic mail at NSSDCA::SPAN_NIC_MGR. _______________________________________________________________________________ TEXNET Most of TEXNET became operational in 1986, although pieces of this network existed earlier. The purpose of the network is to link computers at Texas universities which run the DECnetTM upper layer protocols. Lower layer protocols in use on the network are ethernet (IEEE 802.3) and DDCMP (Digital Data Communication Message Protocol). TEXNET currently connects over 450 machines in 14 cities. The network backbone consists of DECnetTM routers, and some synchronous links, connected via leased lines. 9600 bps and 56 Kbps lines are used. Gateways exist from TEXNET to SPAN, BITNET and the ARPA Internet. Services provided include electronic mail, file transfer and remote login. Operational and policy management of the network is by consensus of an informal management group composed of managers from each member institution. The following institutions are TEXNET members: Baylor University Houston Area Research Center Pan American University Sam Houston State University Southwest Texas State University Texas A & M University University of Houston University of Texas at Arlington University of Texas at Austin University of Texas at El Paso University of Texas at Dallas University of Texas at Permian Basin University of Texas at San Antonio University of Texas at Tyler University of Texas Health Center at Tyler University of Texas Health Science Center at Dallas University of Texas Health Science Center at Houston University of Texas Health Science Center at San Antonio University of Texas Medical Branch Galveston University of Texas System Cancer Center University of Texas System Center for High Performance Computing University of Texas Office of Land Management _______________________________________________________________________________ UUCP and USEnet The UUCP network was started in the 1970's to provide electronic mail and file transfer between UNIX systems. The network is a host-based store-and-forward network using dialup telephone circuits and operates by having each member site dialup the next UUCP host computer and send and receive files and electronic mail messages. The network uses addresses based on the physical path established by this sequence of dialups connections. UUCP is open to any UNIX system which chooses to participate. There are "informal" electronic mail gateways between UUCP and ARPANET, BITNET, or CSNET, so that users of any of these networks can exchange electronic mail. USENET is a UNIX news facility based on the UUCP network that provides a news bulletin board service. USEnet has both academic and commercial members and affiliates in Europe, Asia, and South America. Neither UUCP nor USENET has a central management; volunteers maintain and distribute the routing tables for the network. Each member site pays its own costs and agrees to carry traffic. Despite this reliance on mutual cooperation and anarchic management style, the network operates and provides a useful, if somewhat unreliable, and low-cost service to its members. Over the years the network has grown into a world-wide network with thousands of computers participating. "The Future Is Now" ______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 5 of 13 [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] [] [] [] Control Office Administration [] [] Of Enhanced 911 Services For [] [] Special Services And Major Account Centers [] [] [] [] By The Eavesdropper [] [] [] [] March, 1988 [] [] [] [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] Description of Service ~~~~~~~~~~~~~~~~~~~~~~ The control office for Emergency 911 service is assigned in accordance with the existing standard guidelines to one of the following centers: o Special Services Center (SSC) o Major Accounts Center (MAC) o Serving Test Center (STC) o Toll Control Center (TCC) The SSC/MAC designation is used in this document interchangeably for any of these four centers. The Special Services Centers (SSCs) or Major Account Centers (MACs) have been designated as the trouble reporting contact for all E911 customer (PSAP) reported troubles. Subscribers who have trouble on an E911 call will continue to contact local repair service (CRSAB) who will refer the trouble to the SSC/MAC, when appropriate. Due to the critical nature of E911 service, the control and timely repair of troubles is demanded. As the primary E911 customer contact, the SSC/MAC is in the unique position to monitor the status of the trouble and insure its resolution. System Overview ~~~~~~~~~~~~~~~ The number 911 is intended as a nationwide universal telephone number which provides the public with direct access to a Public Safety Answering Point (PSAP). A PSAP is also referred to as an Emergency Service Bureau (ESB). A PSAP is an agency or facility which is authorized by a municipality to receive and respond to police, fire and/or ambulance services. One or more attendants are located at the PSAP facilities to receive and handle calls of an emergency nature in accordance with the local municipal requirements. An important advantage of E911 emergency service is improved (reduced) response times for emergency services. Also close coordination among agencies providing various emergency services is a valuable capability provided by E911 service. 1A ESS is used as the tandem office for the E911 network to route all 911 calls to the correct (primary) PSAP designated to serve the calling station. The E911 feature was developed primarily to provide routing to the correct PSAP for all 911 calls. Selective routing allows a 911 call originated from a particular station located in a particular district, zone, or town, to be routed to the primary PSAP designated to serve that customer station regardless of wire center boundaries. Thus, selective routing eliminates the problem of wire center boundaries not coinciding with district or other political boundaries. The services available with the E911 feature include: Forced Disconnect Default Routing Alternative Routing Night Service Selective Routing Automatic Number Identification (ANI) Selective Transfer Automatic Location Identification (ALI) Preservice/Installation Guidelines ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When a contract for an E911 system has been signed, it is the responsibility of Network Marketing to establish an implementation/cutover committee which should include a representative from the SSC/MAC. Duties of the E911 Implementation Team include coordination of all phases of the E911 system deployment and the formation of an on-going E911 maintenance subcommittee. Marketing is responsible for providing the following customer specific information to the SSC/MAC prior to the start of call through testing: o All PSAP's (name, address, local contact) o All PSAP circuit ID's o 1004 911 service request including PSAP details on each PSAP (1004 Section K, L, M) o Network configuration o Any vendor information (name, telephone number, equipment) The SSC/MAC needs to know if the equipment and sets at the PSAP are maintained by the BOCs, an independent company, or an outside vendor, or any combination. This information is then entered on the PSAP profile sheets and reviewed quarterly for changes, additions and deletions. Marketing will secure the Major Account Number (MAN) and provide this number to Corporate Communications so that the initial issue of the service orders carry the MAN and can be tracked by the SSC/MAC via CORDNET. PSAP circuits are official services by definition. All service orders required for the installation of the E911 system should include the MAN assigned to the city/county which has purchased the system. In accordance with the basic SSC/MAC strategy for provisioning, the SSC/MAC will be Overall Control Office (OCO) for all Node to PSAP circuits (official services) and any other services for this customer. Training must be scheduled for all SSC/MAC involved personnel during the pre-service stage of the project. The E911 Implementation Team will form the on-going maintenance subcommittee prior to the initial implementation of the E911 system. This sub-committee will establish post implementation quality assurance procedures to ensure that the E911 system continues to provide quality service to the customer. Customer/Company training, trouble reporting interfaces for the customer, telephone company and any involved independent telephone companies needs to be addressed and implemented prior to E911 cutover. These functions can be best addressed by the formation of a sub-committee of the E911 Implementation Team to set up guidelines for and to secure service commitments of interfacing organizations. A SSC/MAC supervisor should chair this subcommittee and include the following organizations: 1) Switching Control Center - E911 translations - Trunking - End office and Tandem office hardware/software 2) Recent Change Memory Administration Center - Daily RC update activity for TN/ESN translations - Processes validity errors and rejects 3) Line and Number Administration - Verification of TN/ESN translations 4) Special Service Center/Major Account Center - Single point of contact for all PSAP and Node to host troubles - Logs, tracks & statusing of all trouble reports - Trouble referral, follow up, and escalation - Customer notification of status and restoration - Analyzation of "chronic" troubles - Testing, installation and maintenance of E911 circuits 5) Installation and Maintenance (SSIM/I&M) - Repair and maintenance of PSAP equipment and Telco owned sets 6) Minicomputer Maintenance Operations Center - E911 circuit maintenance (where applicable) 7) Area Maintenance Engineer - Technical assistance on voice (CO-PSAP) network related E911 troubles Maintenance Guidelines ~~~~~~~~~~~~~~~~~~~~~~ The CCNC will test the Node circuit from the 202T at the Host site to the 202T at the Node site. Since Host to Node (CCNC to MMOC) circuits are official company services, the CCNC will refer all Node circuit troubles to the SSC/MAC. The SSC/MAC is responsible for the testing and follow up to restoration of these circuit troubles. Although Node to PSAP circuit are official services, the MMOC will refer PSAP circuit troubles to the appropriate SSC/MAC. The SSC/MAC is responsible for testing and follow up to restoration of PSAP circuit troubles. The SSC/MAC will also receive reports from CRSAB/IMC(s) on subscriber 911 troubles when they are not line troubles. The SSC/MAC is responsible for testing and restoration of these troubles. Maintenance responsibilities are as follows: SCC* Voice Network (ANI to PSAP) *SCC responsible for tandem switch SSIM/I&M PSAP Equipment (Modems, CIU's, sets) Vendor PSAP Equipment (when CPE) SSC/MAC PSAP to Node circuits, and tandem to PSAP voice circuits (EMNT) MMOC Node site (Modems, cables, etc) Note: All above work groups are required to resolve troubles by interfacing with appropriate work groups for resolution. The Switching Control Center (SCC) is responsible for E911/1AESS translations in tandem central offices. These translations route E911 calls, selective transfer, default routing, speed calling, etc., for each PSAP. The SCC is also responsible for troubleshooting on the voice network (call originating to end office tandem equipment). For example, ANI failures in the originating offices would be a responsibility of the SCC. Recent Change Memory Administration Center (RCMAC) performs the daily tandem translation updates (recent change) for routing of individual telephone numbers. Recent changes are generated from service order activity (new service, address changes, etc.) and compiled into a daily file by the E911 Center (ALI/DMS E911 Computer). SSIM/I&M is responsible for the installation and repair of PSAP equipment. PSAP equipment includes ANI Controller, ALI Controller, data sets, cables, sets, and other peripheral equipment that is not vendor owned. SSIM/I&M is responsible for establishing maintenance test kits, complete with spare parts for PSAP maintenance. This includes test gear, data sets, and ANI/ALI Controller parts. Special Services Center (SSC) or Major Account Center (MAC) serves as the trouble reporting contact for all (PSAP) troubles reported by customer. The SSC/MAC refers troubles to proper organizations for handling and tracks status of troubles, escalating when necessary. The SSC/MAC will close out troubles with customer. The SSC/MAC will analyze all troubles and tracks "chronic" PSAP troubles. Corporate Communications Network Center (CCNC) will test and refer troubles on all node to host circuits. All E911 circuits are classified as official company property. The Minicomputer Maintenance Operations Center (MMOC) maintains the E911 (ALI/DMS) computer hardware at the Host site. This MMOC is also responsible for monitoring the system and reporting certain PSAP and system problems to the local MMOC's, SCC's or SSC/MAC's. The MMOC personnel also operate software programs that maintain the TN data base under the direction of the E911 Center. The maintenance of the NODE computer (the interface between the PSAP and the ALI/DMS computer) is a function of the MMOC at the NODE site. The MMOC's at the NODE sites may also be involved in the testing of NODE to Host circuits. The MMOC will also assist on Host to PSAP and data network related troubles not resolved through standard trouble clearing procedures. Installation And Maintenance Center (IMC) is responsible for referral of E911 subscriber troubles that are not subscriber line problems. E911 Center - Performs the role of System Administration and is responsible for overall operation of the E911 computer software. The E911 Center does A-Z trouble analysis and provides statistical information on the performance of the system. This analysis includes processing PSAP inquiries (trouble reports) and referral of network troubles. The E911 Center also performs daily processing of tandem recent change and provides information to the RCMAC for tandem input. The E911 Center is responsible for daily processing of the ALI/DMS computer data base and provides error files, etc. to the Customer Services department for investigation and correction. The E911 Center participates in all system implementations and on-going maintenance effort and assists in the development of procedures, training and education of information to all groups. Any group receiving a 911 trouble from the SSC/MAC should close out the trouble with the SSC/MAC or provide a status if the trouble has been referred to another group. This will allow the SSC/MAC to provide a status back to the customer or escalate as appropriate. Any group receiving a trouble from the Host site (MMOC or CCNC) should close the trouble back to that group. The MMOC should notify the appropriate SSC/MAC when the Host, Node, or all Node circuits are down so that the SSC/MAC can reply to customer reports that may be called in by the PSAPs. This will eliminate duplicate reporting of troubles. On complete outages the MMOC will follow escalation procedures for a Node after two (2) hours and for a PSAP after four (4) hours. Additionally the MMOC will notify the appropriate SSC/MAC when the Host, Node, or all Node circuits are down. The PSAP will call the SSC/MAC to report E911 troubles. The person reporting the E911 trouble may not have a circuit I.D. and will therefore report the PSAP name and address. Many PSAP troubles are not circuit specific. In those instances where the caller cannot provide a circuit I.D., the SSC/MAC will be required to determine the circuit I.D. using the PSAP profile. Under no circumstances will the SSC/MAC Center refuse to take the trouble. The E911 trouble should be handled as quickly as possible, with the SSC/MAC providing as much assistance as possible while taking the trouble report from the caller. The SSC/MAC will screen/test the trouble to determine the appropriate handoff organization based on the following criteria: PSAP equipment problem: SSIM/I&M Circuit problem: SSC/MAC Voice network problem: SCC (report trunk group number) Problem affecting multiple PSAPs (No ALI report from all PSAPs): Contact the MMOC to check for NODE or Host computer problems before further testing. The SSC/MAC will track the status of reported troubles and escalate as appropriate. The SSC/MAC will close out customer/company reports with the initiating contact. Groups with specific maintenance responsibilities, defined above, will investigate "chronic" troubles upon request from the SSC/MAC and the ongoing maintenance subcommittee. All "out of service" E911 troubles are priority one type reports. One link down to a PSAP is considered a priority one trouble and should be handled as if the PSAP was isolated. The PSAP will report troubles with the ANI controller, ALI controller or set equipment to the SSC/MAC. NO ANI: Where the PSAP reports NO ANI (digital display screen is blank) ask if this condition exists on all screens and on all calls. It is important to differentiate between blank screens and screens displaying 911-00XX, or all zeroes. When the PSAP reports all screens on all calls, ask if there is any voice contact with callers. If there is no voice contact the trouble should be referred to the SCC immediately since 911 calls are not getting through which may require alternate routing of calls to another PSAP. When the PSAP reports this condition on all screens but not all calls and has voice contact with callers, the report should be referred to SSIM/I&M for dispatch. The SSC/MAC should verify with the SCC that ANI is pulsing before dispatching SSIM. When the PSAP reports this condition on one screen for all calls (others work fine) the trouble should be referred to SSIM/I&M for dispatch, because the trouble is isolated to one piece of equipment at the customer premise. An ANI failure (i.e. all zeroes) indicates that the ANI has not been received by the PSAP from the tandem office or was lost by the PSAP ANI controller. The PSAP may receive "02" alarms which can be caused by the ANI controller logging more than three all zero failures on the same trunk. The PSAP has been instructed to report this condition to the SSC/MAC since it could indicate an equipment trouble at the PSAP which might be affecting all subscribers calling into the PSAP. When all zeroes are being received on all calls or "02" alarms continue, a tester should analyze the condition to determine the appropriate action to be taken. The tester must perform cooperative testing with the SCC when there appears to be a problem on the Tandem-PSAP trunks before requesting dispatch. When an occasional all zero condition is reported, the SSC/MAC should dispatch SSIM/I&M to routine equipment on a "chronic" troublesweep. The PSAPs are instructed to report incidental ANI failures to the BOC on a PSAP inquiry trouble ticket (paper) that is sent to the Customer Services E911 group and forwarded to E911 center when required. This usually involves only a particular telephone number and is not a condition that would require a report to the SSC/MAC. Multiple ANI failures which our from the same end office (XX denotes end office), indicate a hard trouble condition may exist in the end office or end office tandem trunks. The PSAP will report this type of condition to the SSC/MAC and the SSC/MAC should refer the report to the SCC responsible for the tandem office. NOTE: XX is the ESCO (Emergency Service Number) associated with the incoming 911 trunks into the tandem. It is important that the C/MAC tell the SCC what is displayed at the PSAP (i.e. 911-0011) which indicates to the SCC which end office is in trouble. Note: It is essential that the PSAP fill out inquiry form on every ANI failure. The PSAP will report a trouble any time an address is not received on an address display (screen blank) E911 call. (If a record is not in the 911 data base or an ANI failure is encountered, the screen will provide a display noticing such condition). The SSC/MAC should verify with the PSAP whether the NO ALI condition is on one screen or all screens. When the condition is on one screen (other screens receive ALI information) the SSC/MAC will request SSIM/I&M to dispatch. If no screens are receiving ALI information, there is usually a circuit trouble between the PSAP and the Host computer. The SSC/MAC should test the trouble and refer for restoral. Note: If the SSC/MAC receives calls from multiple PSAP's, all of which are receiving NO ALI, there is a problem with the Node or Node to Host circuits or the Host computer itself. Before referring the trouble the SSC/MAC should call the MMOC to inquire if the Node or Host is in trouble. Alarm conditions on the ANI controller digital display at the PSAP are to be reported by the PSAP's. These alarms can indicate various trouble conditions o so the SSC/MAC should ask the PSAP if any portion of the E911 system is not functioning properly. The SSC/MAC should verify with the PSAP attendant that the equipment's primary function is answering E911 calls. If it is, the SSC/MAC should request a dispatch SSIM/I&M. If the equipment is not primarily used for E911, then the SSC/MAC should advise PSAP to contact their CPE vendor. Note: These troubles can be quite confusing when the PSAP has vendor equipment mixed in with equipment that the BOC maintains. The Marketing representative should provide the SSC/MAC information concerning any unusual or exception items where the PSAP should contact their vendor. This information should be included in the PSAP profile sheets. ANI or ALI controller down: When the host computer sees the PSAP equipment down and it does not come back up, the MMOC will report the trouble to the SSC/MAC; the equipment is down at the PSAP, a dispatch will be required. PSAP link (circuit) down: The MMOC will provide the SSC/MAC with the circuit ID that the Host computer indicates in trouble. Although each PSAP has two circuits, when either circuit is down the condition must be treated as an emergency since failure of the second circuit will cause the PSAP to be isolated. Any problems that the MMOC identifies from the Node location to the Host computer will be handled directly with the appropriate MMOC(s)/CCNC. Note: The customer will call only when a problem is apparent to the PSAP. When only one circuit is down to the PSAP, the customer may not be aware there is a trouble, even though there is one link down, notification should appear on the PSAP screen. Troubles called into the SSC/MAC from the MMOC or other company employee should not be closed out by calling the PSAP since it may result in the customer responding that they do not have a trouble. These reports can only be closed out by receiving information that the trouble was fixed and by checking with the company employee that reported the trouble. The MMOC personnel will be able to verify that the trouble has cleared by reviewing a printout from the host. When the CRSAB receives a subscriber complaint (i.e., cannot dial 911) the RSA should obtain as much information as possible while the customer is on the line. For example, what happened when the subscriber dialed 911? The report is automatically directed to the IMC for subscriber line testing. When no line trouble is found, the IMC will refer the trouble condition to the SSC/MAC. The SSC/MAC will contact Customer Services E911 Group and verify that the subscriber should be able to call 911 and obtain the ESN. The SSC/MAC will verify the ESN via 2SCCS. When both verifications match, the SSC/MAC will refer the report to the SCC responsible for the 911 tandem office for investigation and resolution. The MAC is responsible for tracking the trouble and informing the IMC when it is resolved. For more information, please refer to E911 Glossary of Terms. _______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 6 of 13 [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] [] [] [] Glossary Terminology [] [] For Enhanced 911 Services [] [] [] [] By The Eavesdropper [] [] [] [] March, 1988 [] [] [] [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] E911 - Enhanced 911: Features available include selective routing, selective transfer, fixed transfer, alternate routing, default routing, Automatic Number Display, Automatic Location Identification, night service, default routing, call detail record. End Office - Telephone central office which provides dial tone to the subscriber calling 911. The "end office" provides ANI (Automatic Number Identification) to the tandem office. Tandem Office - Telephone central office which serves as a tandem (or hub) for all 911 calls. Must be a 1AESS type of central office. The tandem office translations contain the TN/ESN relationships which route the 911 call to the proper SAP. The tandem office looks up the ANI (TN) that it receives from the end office and finds the ESN (routing information) which corresponds to a seven digit number ringing in at a PSAP. PSAP - Public Safety Answering Point, usually the police, fire and/or rescue groups as determined by the local municipalities. A "ringin" will not have ANI or ALI capabilities, but just receives calls or transferred calls from another PSAP. ESN - Emergency Service Number (XXX) that is assigned to the subscriber's telephone number in the tandem office translations The ESN represents a seven digit number by which the tandem office routes the call to the proper PSAP. PSAPs with ALI capabilities also receive a display of the ESN information which shows which police, fire and rescue agency serves the telephone number calling 911. An ESN is a unique combination of police, fire, and rescue service for purposes of routing the E911 call. ANI - Automatic Number Identification corresponds to the subscriber's seven digit telephone number. The ANI displays at the PSAP on the digital ANI display console. ALI - Automatic Location Identification provides for an address display of the subscriber calling 911. With ALI, the PSAP receives the ANI display and an ALI display on a screen. The ALI display includes the subscriber's address, community, state, type of service and if a business, the name of the business. The PSAP will also get a display of the associated ESN information (police, fire, rescue). Selective Routing - The capability to route a call to the particular PSAP serving the address associated with the TN making the 911 call. Selective routing is achieved by building TN/ESN translations in the tandem central office. These translations are driven by the E911 data base which assigns the ESN to each telephone number based on the customer's address. Service order activity keeps the E911 data base updated. The E911 data base, in turn, generates recent change to the tandem office (through the SCC or RCMAC) to update the TN/ESN translations in the tandem data base. Selective Transfer - Provides the PSAP with the ability to transfer the incoming 911 call to a fire or rescue service for the particular number calling 911 by pushing one button for fire or rescue. For example, if an incoming 911 call was reporting a fire, the PSAP operator would push the fire button on the ANI console; the call would go back to the tandem office, do a lookup for the seven digit number associated with fire department, for the ESN assigned to the calling TN, and automatically route the call to that fire department. This differs from "fixed" transfer which routes every call to the same fire or rescue number whenever the fire or rescue button is pushed. The PSAP equipment is optioned to provide either fixed or selective transfer capabilities. Alternate Routing - Alternate routing provides for a predetermined routing for 911 calls when the tandem office is unable to route the calls over the 911 trunks for a particular PSAP due to troubles or all trunks busy. Default Routing - Provides for routing of 911 calls when there is an ANI failure. The call will be routed to the "default" ESN associated with the he NNX the caller is calling from. Default ESNs are preassigned in translations and are usually the predominant ESN for a given wire center. Night Service - Night service works the same as alternate routing in that the calls coming into a given PSAP will automatically be routed to another preset PSAP when all trunks are made busy due to the PSAP closing down for the night. Call Detail Record - When the 911 call is terminated by the PSAP operator, the ANI will automatically print-out on the teletypewriter located at the PSAP. The printout will contain the time the call came into the PSAP, the time it was picked up by an operator, the operator number, the time the call was transferred, if applicable, the time the call was terminated and the trunk group number associated with the call. Printouts of the ALI display are now also available, if the PSAP has purchased the required equipment. ANI Failure - Failure of the end office to identify the call and provide the ANI (telephone number) to the tandem office; or, an ANI failure between the tandem office and the PSAP. Misroute - Any condition that results in the 911 call going to the wrong PSAP. A call can be misrouted if the ESN and associated routing information are incorrect in the E911 data base and/or tandem data base. A call can also be misrouted if the call is an ANI failure, which automatically default routes. Anonymous Call - If a subscriber misdials and dials the seven digit number associated with the PSAP position, they will come in direct and ANI display as 911-0000 which will ALI as an anonymous call. The seven digit numbers associated with the PSAP positions are not published even to the PSAPs. Spurious 911 Call - Occasionally, the PSAP will get a call that is not associated with a subscriber dialing 911 for an emergency. It could be a subscriber who has not dialed 911, but is dialing another number, or has just picked up their phone and was connected with the PSAP. These problems are equipment related, particularly when the calls originate from electromechanical or step by step offices, and are reported by the E911 Center to Network Operations upon receipt of the PSAP inquiry reporting the trouble. The PSAP may get a call and no one is there; if they call the number back, the number may be disconnected or no one home. Again these are network troubles and must be investigated. Cordless telephones can also generate "spurious" calls in to the PSAPs. Generally, the PSAP will hear conversation on the line, but the subscribers are not calling 911. The PSAP may report spurious calls to to repair if they become bothersome, for example, the same number ringing in continually. No Displays - A condition where the PSAP ALI display screen is blank. This type of trouble should be reported immediately to the SSC/MAC. If all screens at the PSAP are blank, it is an indication that the problem is in the circuits from the PSAP to the E911 computer. If more than one PSAP is experiencing no display, it may be a problem with the Node computer or the E911 computer. The SSC/MAC should contact the MMOC to determine the health of the HOST computer. Record Not Found - If the host computer is unable to do a look up on a given ANI request from the PSAP, it will forward a Record Not Found message to the PSA ALI screen. This is caused by service order activity for a given subscriber not being processed into the E911 data base, or HOST computer system problems whereby the record cannot be accessed at that point in time. No ANI - This condition means the PSAP received a call, but no telephone number displayed on the ANI console. The PSAP should report this condition immediately to the SSC/MAC. PSAP Not Receiving Calls - If a PSAP cannot receive calls or request retrievals from the E911 host computer, i.e., cable cut, the calls into that PSAP must be rerouted to another PSAP. The Switching Control Center must be notified to reroute the calls in the tandem office E911 translations. MSAG - Master Street Address Guide. The MSAG ledgers are controlled by the municipality which has purchased the E911 ALI service, in that they assign which police, fire or rescue agency will serve a given street and number range. They do this by assigning an ESN to each street range, odd, even, community that is populated in the county or municipality served. These MSAGs are then used as a filter for service order activity into the E911 computer data base to assign ESNs to individual TN records. This insures that each customer will be routed to the correct agency for their particular address. In a non-ALI County, TAR codes are used by the Telephone company to assign ESNs to service conductivity and the County does not control the ESN assignment. TAR codes represent the taxing authority for the given subscriber which should correspond to their police, fire and rescue agencies. The MG method, of course, is more accurate because it is using the actual service address of the customer to route the call and provides the county with more flexibility in assigning fire and rescue district, etc. The Customer Services E911 Group maintains the E911 computer data base and interfaces with the County (customer) on all MSAG or data base activity. _______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 7 of 13 ()()()()()()()()()()()()()()()()()()()()()()()() () () () Advanced Bitnet Procedures () () () () by () () () () VAXBusters International () () () ()()()()()()()()()()()()()()()()()()()()()()()() Greetings! I have taken the time to write up a file about some of the more complex operations on Bitnet. I hope you enjoy it! :-) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - You can send multiple messages to one user@node under VAX/VMS & JNET by just typing; $ SEND/REMOTE This will collect messages from the terminal until an empty line or CTRL-Z is entered. Under Unix, the UREP package is popular to connect Unix boxes to Bitnet. The important user commands are as follows: Messages ~~~~~~~~ netwrite user@host Send one or more messages to the specified Bitnet user. Netwrite reads messages from it's standard input until an EOF is reached. If called from a terminal, netwrite will terminate on an empty line as well. When you receive Bitnet messages on a Unix host, UREP looks for an executable file named .exwrite in your home directory. If it doesn't find such a file, the message is simply spit on your terminal. If .exwrite is present, UREP executes this program (which can be a shell script) with five parameters: The parameter tells the terminal to which UREP wanted to send the message. UREP then feeds the messages to .exwrite as standard input. The format of standard input is as follows: bytes)> To display these messages you need to have a "C" program, since a shell script is not capable of handling single bytes painlessly. I included my exwrite.c at the end of this file for a start. Typically, .exwrite is used to log all incoming Bitnet messages. You can of course blow it up to send messages back to the sender when you're out to lunch, etc. BTW, .exwrite is called with the user ID of the receiving user, so it's no real security hole. File Transfer ~~~~~~~~~~~~~ netcopy user@host [ options ] Copy a file to the specified Bitnet user. The most important option is "name=.", with which you can specify the file name to be used at the recipient's machine. More details are in the manual page. When you receive Bitnet files on a Unix machine running UREP, they will be placed in your home directory under the name ":.". These files are in NETDATA format, and they have to be converted to ASCII text files when you want to use them under Unix. This can be done with the command; netdata [ [ ] ] When is unspecified, standard input is used. If is unspecified, standard output is used. Bitnet Commands ~~~~~~~~~~~~~~~ Though Bitnet has no remote login capability, you can execute a (restricted) set of commands on remote hosts. These commands can be used to query node status, lists of logged-on users, time and some other things. This works as follows: JNET: $ SEND/COMMAND [ ] UREP: % netexec [ ] CMS: SMSG CMD The under CMS is the Bitnet control process. In Europe, it is normally called "EARN." In the USA, it could be "BITNET" or maybe "RSCS." You're on your own here. The is the Bitnet host name which you want to execute the . With JNET and UREP, you will be asked for multiple commands when you leave the field empty. Again, input is terminated with EOF or an empty line. I have found the following commands useful in daily life: CPQ N Get a list of the users currently logged in at the . This command is supposed to exist on every Bitnet host, but some system managers like to restrict it for security reasons. On JNET and UREP hosts, FINGER performs a similar, but more elaborate function. CPQ T Make tell you the current time at it's location. Q Make tell you what the next hop to is. This is useful when you're interested in the network topology. Q A This makes tell you what file is currently active (being transmitted) for . This only works for machines which are directly connected to . Q Q This makes show you the queue of files currently waiting for transmission to . This is useful when you want to trace some file which you sent to the network. Q SYS This makes tell you about the RSCS links it has. Unfortunately, MVS-Hosts don't understand any of these commands, but simply give an error message. You can recognize these things by the string "HASP" somewhere in the error message. Enjoy ! exwrite.c For Unix Hosts Running UREP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <-- cut here --> /* exwrite.c - formatter for UREP rscs messages */ include include include include main(argc, argv) int argc; char *argv[]; struct passwd *pw; char fname[255]; FILE *term; FILE *log; int count; char buf[1024]; char *from_user; char *from_host; char *to_user; char *to_host; char *to_tty; char *home_dir = "/tmp"; if (argc != 6) fprintf(stderr, "%s: Invalid arguments\n", argv[0]); exit(EX_USAGE); /* initialise variables */ to_host = argv[1]; to_user = argv[2]; from_host = argv[3]; from_user = argv[4]; to_tty = argv[5]; /* convert the receiving user to lowercase. Under Unix, all * * user names normally are lower case, and we need a valid * * user name to determine the home directory */ for (; *to_user; to_user++) *to_user = tolower(*to_user); to_user = argv[2]; /* get the home directory of the receiving user */ if (pw = getpwnam(to_user)) home_dir = pw->pw_dir; /* open the terminal, exit if the open fails */ sprintf(fname, "/dev/%s", to_tty); if (!(term = fopen(fname, "w"))) exit(EX_OSERR); /* open the rscs log file */ sprintf(fname, "%s/.rscslog", home_dir); log = fopen(fname, "a"); /* if the message is not coming from the relay, write the * * sending user and host name to the specified terminal */ if (strcmp(from_user, "RELAY")) fprintf(term, "From %s@%s:\r\n", from_user, from_host); /* read in the RSCS messages and send them to the terminal * * and to the logfile if it has been opened. * * In the log file, all lines are preceded by the sending user * * and host name. */ while ((count = getchar()) != EOF) if ((count = fread(buf, 1, count, stdin)) > 0) fwrite(buf, 1, count, term); fprintf(term, "\r\n"); if (log) fprintf(log, "%s@%s: ", from_user, from_host); fwrite(buf, 1, count, log); fprintf(log, "\n"); exit(EX_OK); _______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 8 of 13 /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ Special Area Codes /^\ /^\ /^\ /^\ by >Unknown User< /^\ /^\ /^\ /^\ January 3, 1989 /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ /^\ Greetings! I have compiled information about the SACs for your edification; these include 700, 800, and 900. Most telephone users from the United States are quite familiar with 800 service: A number that they dial and incur NO charge (not even message units in most areas). Then there is 900 service, which is what most people perceive as 'value added,' i.e. you pay more for the information than for the transport of the call. These vary typically from 35 cents to a few dollars for either a timed service, or a 'as long as you like' duration-sensitive service. There are two sub-species of 900 service: AT&T and "everybody else." Finally, there is 700 service, which many people remember as Alliance Teleconferencing. This is the third "canonical" SAC. With few limitations, this SAC is given over to the IEC entirely. Let's look at these in more detail. 800 Service ~~~~~~~~~~~ 800 service is offered by various IECs. Each NXX in the 800 SAC is assigned to a given carrier, who is responsible for assigning numbers from that block to customers, and providing 10 digit translation. The carrier must have Feature Group D presence for originating calls from the originating exchange (either direct, or through an access tandem). In the future, when CCIS becomes wide-spread, a query will be made in the database [Who gets 1-800-985-1234?] and the call will be routed appropriately. To clarify: Now the carrier is determined by the NNX. In the future, the carrier will be determined by the entire 7 digits. A similar situation exists with 900 service. Each carrier can reserve NXXs from BellCore (the people who among a zillion other tasks are in charge of handing out prefixes and area codes). They're not cheap! To get the actual number is free (there are qualifications that I don't deal with), but to get it 'turned on' in a LATA costs you money, depending on: (1) How many prefixes you're getting, (2) Whether it's 800 or 900 service; and, (3) How many Tandems/End Offices are in the LATA. It requires a discrete amount of labor for EACH office, because EACH routing table must be modified. However, I will be discussing 900 Service in more detail later in this file. When you, as Joe Customer, dial 1-800-222-1234 (made up number, please don't bother them) it will initiate the following sequence: 1. If you are in an Electronic Office (DMS-100, DMS-200, 1A ESS, 5 ESS) the 800-222 will be translated to "AT&T" and will search for an opening in a trunk group marked for 800 origination. Should none be found, bump to step 3. 2. If you are in a non-electronic office (SxS, XB, and some flavors of ESS), it will go to the access tandem that your office 'homes' on, where 800-222 will be translated to "AT&T." Note: If at this point, the number doesn't have a translation, you will get a "lose" recording from the CO. 3. Find a trunk in a trunk group marked for 800 origination. Should none be found, give the customer a recording "Due to network congestion, your 800 call could not be completed" or die, or whatever. (Depends on phase of moon, etc.) 4. The end office will the send the following pulse-stream (in MF): KP + II + 3/10D + ST + KP + 800 222 1234 + ST Note: This is a simplification; there are some fine points of ANI spills that are beyond the scope of this file. II = 2 information digits. Typical values are: 00 normal ANI .. 10 digits follow 01 ONI line ... NPA follows 02 ANI failure ... NPA follows 3/10D = 3 or 10 digits. Either the NPA, or the entire 10 digit number. KP and ST are control tones. 5. The carrier receives all of this (and probably throws the ANI into the bit bucket) and translates the 800 number to what's called a PTN, or Plant Test Number (for example, 617-555-9111). Then, the call is routed AS IF the customer had dialed that 10 digit number. Of course, the billing data is marked as an 800 call, so the subscriber receiving the call pays the appropriate amount. Of the 800 possible NXXs, 409 are currently assigned. A long-distance carrier can get one 800 and four 900 numbers just for the paperwork. But to get more than that, you have to show that you're 70% full now, and demonstrate a real need for the capacity. I have included the entire 800-NXX to long-distance carrier translation table. Note that not every NXX is valid in every area. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Revised 800/OCN Translation Table Effective October 10, 1988 221 ATX 222 ATX 223 ATX 224 LDL 225 ATX 226 MIC 227 ATX 228 ATX 229 TDX 230 NTK 231 ATX 232 ATX 233 ATX 234 MCI 235 ATX 236 SCH 237 ATX 238 ATX 239 DLT 240 SIR 241 ATX 242 ATX 243 ATX 244 --- 245 ATX 246 --- 247 ATX 248 ATX 249 --- 250 --- 251 ATX 252 ATX 253 ATX 254 TTU 255 ATX 256 LSI 257 ATX 258 ATX 259 --- 260 --- 261 SCH 262 ATX 263 CAN 264 ICT 265 CAN 266 CSY 267 CAN 268 CAN 269 FDG 270 --- 271 --- 272 ATX 273 --- 274 MCI 275 ITT 276 ONE 277 SNT 278 --- 279 MAL 280 ADG 281 --- 282 ATX 283 MCI 284 MCI 285 --- 286 --- 287 --- 288 MCI 289 MCI 290 --- 291 --- 292 ATX 293 PRO 294 --- 295 --- 296 --- 297 ARE 298 --- 299 CYT 321 ATX 322 ATX 323 ATX 324 HNI 325 ATX 326 UTC 327 ATX 328 ATX 329 TET 330 TET 331 ATX 332 ATX 333 MCI 334 ATX 335 SCH 336 ATX 337 FST 338 ATX 339 --- 340 --- 341 ATX 342 ATX 343 ATX 344 ATX 345 ATX 346 ATX 347 UTC 348 ATX 349 DCT 350 CSY 351 ATX 352 ATX 353 --- 354 --- 355 --- 356 ATX 357 --- 358 ATX 359 UTC 360 --- 361 CAN 362 ATX 363 CAN 364 HNI 365 MCI 366 UTC 367 ATX 368 ATX 369 TDD 370 TDD 371 --- 372 ATX 373 TDD 374 --- 375 TNO 376 --- 377 GTS 378 --- 379 --- 380 --- 381 --- 382 ATX 383 TDD 384 FDT 385 CAB 386 TBQ 387 CAN 388 --- 389 --- 390 --- 391 --- 392 ATX 393 EXF 394 --- 395 --- 396 --- 397 TDD 398 --- 399 ARZ 421 ATX 422 ATX 423 ATX 424 ATX 425 TTH 426 ATX 427 --- 428 ATX 429 --- 430 --- 431 ATX 432 ATX 433 ATX 434 AGN 435 ATX 436 IDN 437 ATX 438 ATX 439 --- 440 TXN 441 ATX 442 ATX 443 ATX 444 MCI 445 ATX 446 ATX 447 ATX 448 ATX 449 --- 450 USL 451 ATX 452 ATX 453 ATX 454 ALN 455 --- 456 MCI 457 ATX 458 ATX 459 --- 460 --- 461 CAN 462 ATX 463 CAN 464 --- 465 CAN 466 ALN 467 ICT 468 ATX 469 --- 470 --- 471 ALN 472 ATX 473 --- 474 --- 475 TDD 476 TDD 477 --- 478 AAM 479 --- 480 --- 481 --- 482 ATX 483 --- 484 TDD 485 TDD 486 TDX 487 --- 488 --- 489 TOM 490 --- 491 --- 492 ATX 493 --- 494 --- 495 --- 496 --- 497 --- 498 --- 499 --- 521 ATX 522 ATX 523 ATX 524 ATX 525 ATX 526 ATX 527 ATX 528 ATX 529 MIT 530 --- 531 ATX 532 ATX 533 ATX 534 --- 535 ATX 536 ALN 537 ATX 538 ATX 539 --- 540 --- 541 ATX 542 ATX 543 ATX 544 ATX 545 ATX 546 UTC 547 ATX 548 ATX 549 --- 550 CMA 551 ATX 552 ATX 553 ATX 554 ATX 555 ATX 556 ATX 557 ALN 558 ATX 559 --- 560 --- 561 CAN 562 ATX 563 CAN 564 --- 565 CAN 566 ALN 567 CAN 568 --- 569 --- 570 --- 571 --- 572 ATX 573 --- 574 AMM 575 --- 576 --- 577 GTS 578 --- 579 LNS 580 WES 581 --- 582 ATX 583 TDD 584 TDD 585 --- 586 ATC 587 LTQ 588 ATC 589 LGT 590 --- 591 --- 592 ATX 593 TDD 594 TDD 595 --- 596 --- 597 --- 598 --- 599 --- 621 ATX 622 ATX 623 --- 624 ATX 625 NLD 626 ATX 627 MCI 628 ATX 629 --- 630 --- 631 ATX 632 ATX 633 ATX 634 ATX 635 ATX 636 CQU 637 ATX 638 ATX 639 BUR 640 --- 641 ATX 642 ATX 643 ATX 644 CMA 645 ATX 646 --- 647 ATX 648 ATX 649 --- 650 --- 651 --- 652 ATX 653 --- 654 ATX 655 --- 656 --- 657 TDD 658 TDD 659 --- 660 --- 661 CAN 662 ATX 663 CAN 664 UTC 665 CAN 666 MCI 667 CAN 668 CAN 669 UTC 670 --- 671 --- 672 ATX 673 TDD 674 TDD 675 --- 676 --- 677 --- 678 MCI 679 --- 680 --- 681 --- 682 ATX 683 MTD 684 --- 685 --- 686 LGT 687 NTS 688 --- 689 --- 690 --- 691 --- 692 ATX 693 --- 694 --- 695 --- 696 --- 697 --- 698 NYC 699 PLG 720 TGN 721 --- 722 ATX 723 --- 724 RTC 725 SAN 726 UTC 727 MCI 728 TDD 729 UTC 730 --- 731 --- 732 ATX 733 UTC 734 --- 735 UTC 736 UTC 737 MEC 738 MEC 739 --- 740 --- 741 MIC 742 ATX 743 EDS 744 --- 745 --- 746 --- 747 TDD 748 TDD 749 TDD 750 --- 751 --- 752 ATX 753 --- 754 TSH 755 --- 756 --- 757 TID 758 --- 759 MCI 760 --- 761 --- 762 ATX 763 --- 764 AAM 765 --- 766 --- 767 UTC 768 SNT 769 --- 770 GCN 771 SNT 772 ATX 773 CUX 774 --- 775 --- 776 UTC 777 MCI 778 UTC 779 TDD 780 TDD 781 --- 782 ATX 783 ALN 784 ALG 785 SNH 786 *1 787 --- 788 --- 789 TMU 790 --- 791 --- 792 ATX 793 --- 794 --- 795 --- 796 --- 797 TID 798 TDD 799 --- 821 ATX 822 ATX 823 THA 824 ATX 825 MCI 826 ATX 827 UTC 828 ATX 829 UTC 830 --- 831 ATX 832 ATX 833 ATX 834 --- 835 ATX 836 TDD 837 TDD 838 --- 839 VST 840 --- 841 ATX 842 ATX 843 ATX 844 LDD 845 ATX 846 --- 847 ATX 848 ATX 849 --- 850 TKC 851 ATX 852 ATX 853 --- 854 ATX 855 ATX 856 --- 857 TLS 858 ATX 859 --- 860 --- 861 --- 862 ATX 863 ALN 864 TEN 865 --- 866 --- 867 --- 868 SNT 869 UTC 870 --- 871 --- 872 ATX 873 MCI 874 ATX 875 ALN 876 MCI 877 UTC 878 ALN 879 --- 880 NAS 881 NAS 882 ATX 883 --- 884 --- 885 ATX 886 ALN 887 ETS 888 MCI 889 --- 890 --- 891 --- 892 ATX 893 --- 894 --- 895 --- 896 TXN 897 --- 898 CGI 899 TDX 921 --- 922 ATX 923 ALN 924 --- 925 --- 926 --- 927 --- 928 CIS 929 --- 930 --- 931 --- 932 ATX 933 --- 934 --- 935 --- 936 RBW 937 MCI 938 --- 939 --- 940 TSF 941 --- 942 ATX 943 --- 944 --- 945 --- 946 --- 947 --- 948 --- 949 --- 950 MCI 951 BML 952 ATX 953 --- 954 --- 955 MCI 956 --- 957 --- 958 *2 959 *2 960 CNO 961 --- 962 ATX 963 SOC 964 --- 965 --- 966 TDX 967 --- 968 TED 969 TDX 970 --- 971 --- 972 ATX 973 --- 974 --- 975 --- 976 --- 977 --- 978 --- 979 --- 980 --- 981 --- 982 ATX 983 WUT 984 --- 985 --- 986 WUT 987 --- 988 WUT 989 TDX 990 --- 991 --- 992 ATX 993 --- 994 --- 995 --- 996 VOA 997 --- 998 --- 999 MCI Notes ~~~~~ *1 -- Released For Future Assignment *2 -- These NXX codes are generally reserved for test applications; They may be reserved for Access Tandem testing from an End Office. Note also: The following NXXs are dedicated for RCCP (Radio Common Carrier Paging) under the discretion of the local exchange carrier: 202, 212, 302, 312, 402, 412, 502, 512, 602, 612, 702, 712, 802, 812, 902, and 912. OCN Reference List ~~~~~~~~~~~~~~~~~~ ADG - Advantage Network, Inc. AGN - AMRIGON ALG - Allnet Communication Services AMM - Access Long Distance AAM - ALASCOM ARE - American Express TRS ARZ - AmeriCall Corporation (Calif.) ATC - Action Telecom Co. ATX - AT&T BML - Phone America BUR - Burlington Tel. CAB - Hedges Communications CAN - Telcom Canada CNO - COMTEL of New Orleans CQU - ConQuest Comm. Corp CSY - COM Systems CUX - Compu-Tel Inc. CYT - ClayDesta Communications DCT - Direct Communications, Inc. DLT - Delta Communications, Inc. EDS - Electronic Data Systems Corp. ETS - Eastern Telephone Systems, Inc. EXF - Execulines of Florida, Inc. FDG - First Digital Network FDN - Florida Digital Network FDT - Friend Technologies FST - First Data Resources GCN - General Communications, Inc. GTS - Telenet Comm. Corp. HNI - Houston Network, Inc. ITT - United States Transmission System LDD - LDDS-II, Inc. LDL - Long Distance for Less LGT - LITEL LNS - Lintel Systems LSI - Long Distance Savers LTQ - Long Distance for Less MAL - MIDAMERICAN MCI - MCI Telecommunications Corp. MDE - Meade Associates MEC - Mercury, Inc. MIC - Microtel, Inc. MIT - Midco Communications MTD - Metromedia Long Distance NLD - National Data Corp. NTK - Network Telemanagement Svcs. NTS - NTS Communications ONC - OMNICALL, Inc. ONE - One Call Communications, Inc. PHE - Phone Mail, Inc. PLG - Pilgrim Telephone Co. PRO - PROTO-COL RBW - R-Comm RTC - RCI Corporation SAN - Satelco SCH - Schneider Communications SDY - TELVUE Corp. SIR - Southern Interexchange Services SLS - Southland Systems, Inc. SNH - Sunshine Telephone Co. SNT - SouthernNet, Inc. SOC - State of California TBQ - Telecable Corp. TDD - Teleconnect TDX - Cable & Wireless Comm. TED - TeleDial America TEM - Telesystems, Inc. TEN - Telesphere Network, Inc. TET - Teltec Savings Communications Co TGN - Telemanagement Consult't Corp. THA - Touch America TID - TMC South Central Indiana TKC - TK Communications, Inc. TLS - TELE-SAV TMU - Tel-America, Inc. TNO - ATC Cignal Communications TOM - TMC of Montgomery TOR - TMC of Orlando TSF - SOUTH-TEL TSH - Tel-Share TTH - Tele Tech, Inc. TTU - Total-Tel USA TXN - Tex-Net USL - U.S. Link Long Distance UTC - U.S. Telcom, Inc. (U.S. Sprint) VOA - Valu-Line VST - STAR-LINE WES - Westel WUT - Western Union Telegraph Co. NOTE: Where local telcos, such as Illinois Bell, offer 800 service, they purchase blocks of numbers from AT&T on prefixes assigned to AT&T. They are free to purchase blocks of numbers from any carrier of their choice however. This list also applies to the 900/OCN Translation Table (presented later in this file). 900 Service ~~~~~~~~~~~ As I mentioned earlier there are two flavors of 900 service, AT&T and "everybody else." Everybody else is handled exactly as the 800 service above, except the IEC will probably use the ANI information to send you a bill (either directly, or through your BOC, each situation governed by applicable tariffs and contractual arrangements between the IEC and the BOC). AT&T 900 is a curious monster indeed. It was designed as a "mass termination" service. When you dial a 900 by AT&T (such as the "hear space shuttle mission audio" number) you get routed to one of twelve "nodes" strewn throughout the country. These nodes are each capable of terminating 9,000 calls >PER SECOND<. There are several options available where the customer and/or the IP pay for all/part of the call. The big difference between 800 and AT&T 900 is >NOT< "who pays for the call" (there are free 900 numbers), but "how many people can it handle at once." The IP is responsible for providing program audio. AT&T is prohibited from providing audio-program services (i.e. tape recorded messages). As with any rule, there are exceptions to these as well. I have included the entire 900-NXX to long-distance carrier translation table. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Revised 900/OCN Translation Table Effective October 10, 1988 Please note that this differs from the 800 table, because much fewer of the 900 NXXs are assigned. NXX OCN NXX OCN NXX OCN NXX OCN NXX OCN 200 ATX 202 Ameritech 210 ATX 220 ATX 221 TDX 222 ONC 223 TDX 225 Pac. Bell 226 MCI 233 TDX 234 TEN 240 U.S. West 248 Ameritech 250 ATX 258 TEN 254 TTU 255 SNT 260 ATX 264 ADG 266 CSY 272 Bell Atl. 273 CAN 275 ITT 280 Ameritech 282 LGT 283 Pac. Bell 288 GTE N.west 297 CAN 300 ATX 301 Ameritech 302 Ameritech 303 Pac. Bell 321 TEN 322 TDX 327 ETS 328 ATX 331 TET 332 PLG 333 U.S. West 335 Bell Atl. 342 ATX 344 ATX 345 ALN 346 United Tel. 350 ATX 364 GTE N.West 366 ONC 369 TEN 370 ATX 377 GTS 386 United Tel. 388 SNT 399 ARZ 400 ATX 407 ATX 410 ATX 420 ATX 422 ALN 426 PLG 428 Ameritech 430 U.S. West 444 ONC 445 PHE 446 MCI 450 Ameritech 451 CAN 456 TEN 463 United Tel. 478 AAM 479 ARZ 480 ATX 483 GTE Midwest 488 ONC 490 U.S. West 500 ATX 505 Pac. Bell 520 ATX 529 MIT 536 BUR 540 ALN 543 ALN 545 GTE Calif. 550 ALN 555 ATX 567 ALN 580 U.S. West 590 ATX 595 CAN 600 ATX 620 Ameritech 624 Pac. Bell 626 CSY 628 Ameritech 630 CAN 633 MIT 639 PLG 643 CAN 645 CAN 650 ATX 654 TEN 656 SNT 660 ATX 661 United Tel. 663 MDE 665 ALN 666 ONC 670 CAN 677 CAN 678 MCI 680 ATX 686 LTG 690 CAN 698 NY Tel. 699 PLG 701 Bell Atl. 710 TGN 720 ATX 722 Pac. Bell 724 RTC 725 SNT 727 GTE Calif. 730 ATX 739 CSY 740 ATX 741 TEN 746 ITT 750 CAN 753 ALN 765 ALN 773 ATX 777 Pac. Bell 778 Ameritech 780 Ameritech 786 ATX 790 CAN 792 CAN 801 Bell Atl. 820 ATX 830 CAN 843 Pac. Bell 844 Pac. Bell 847 United Tel. 850 ATX 860 ATX 866 AAM 870 CAN 872 TEN 887 ETS 888 CIS 900 TDX 901 Bell Atl. 903 ATX 909 ATX 924 Ameritech 932 ATX 948 ARZ 949 MIC 963 TEN 970 MIC 971 MIC 972 MIC 973 MIC 974 ALN 975 ALN 976 ATX 988 MCI 990 MCI 991 ALG 993 SNT 999 TEN 700 Service ~~~~~~~~~~~ The last SAC we'll deal with is 700. I've seen ads on late-night television for Group Access Bridging service (GAB) under 700 numbers, with an elephantine dialing sequence. The one that comes to mind is 10041-1-700-777-7777. If you were to dial 1-700-555-4141 you will hear a recording announcing your Equal-Access carrier. (Some carriers ignore the last four digits, and any 700-555 number will give the announcement). This is signalled the same as 800 service, and may or may not be billed ENTIRELY at the discretion of the IEC. In New York, under PSC tariff, you can order 900 and/or 700 blocking as well as 976, 970, 550, and 540 blocking in various combinations. What in ONE carrier might be a customer service hotline (Dial 1-700-I AM LOST) might for another be a revenue product. There is LITTLE standardization of 700 usage from IEC to IEC. The one last dialing pattern that is worth mentioning is what's called, "cut through dialing." Try dialing 10220. If Western Union comes to your town, you'll get a FG-A style dial tone. Presumably if you had a Western Union "Calling Card" you could dial a call. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Glossary ~~~~~~~~ ANI - Automatic Number Identification. An MF sequence that identifies your line for toll billing information. Often confused with ANAC (Automatic Number Announcement Circuit) which reads your number back in a synthesized voice. BOC - Bell Operating Company. An often misused term that in general usage means, "Your local exchange carrier." Since most of the telephones in the country are served by what used to be the Bell system, we tend to use the term. The proper term in this case, however IS "Exchange Carrier [EC]" They provide service within your LATA. FG-A - Feature Group A. Line Side termination for Long Distance carriers. The old 555-1234 for Widget Telephone Company then dial an access code and the number style dialing is called FG-A. FG-B - Feature Group B. Trunk Side termination for Long Distance carriers. (aka ENFIA B). 950 service. This is LATA wide service, and doesn't cost the customer message units. ANI is only provided when the trunks terminate in the End Office (as opposed to an access tandem). FG-D - Feature Group D. Trunk Side termination. Provides 10xxx dialing, 1+ pre-subscription dialing, and Equal Access 800/900 service. Only available in electronic offices and some 5XB offices (through a beastie called an Adjunct Frame.) GAB - Group Audio Bridging. Where several people call the same number, to talk to other people calling the same number. "Party" or "Chat" lines. IEC - Inter-Exchange Carrier. Someone who actually carries calls from place to place. AT&T, Sprint, MCI are all IECs. IP - Information Provider. Someone who sells a value-added service over the telephone. Where you pay for the INFORMATION you're receiving, as well as the cost of TRANSPORT of the call. NXX - Notation convention for what used to be called a "prefix". N represents the digits 2 through 9, and X represents the digits 0 through 9. There are 800 valid NXX combinations, but some are reserved for local use. (411 for Directory, 611 for Repair Bureau, 911 for emergency, etc.) ONI - Operator Number Identification. In areas with some styles of party-line service, the CO cannot tell who you are, and the operator will come on and say, "What number are you calling from?". You can lie, they have to trust you. They MAY know which PREFIX you're coming from, though. PTN - Plant Test Number. A regular 10 digit number assigned with your inward WATS line. This may NOT be a 'dialable' number from the local CO. (A friend has a WATS line in Amherst, MA [413-549, dial the PTN locally, but you can if you come in on a toll trunk.) SAC - Special Area Code. Bellcore speak for area codes that aren't really places, but classes of service. _______________________________________________________________________________ ==Phrack Inc.== Volume Two, Issue 24, File 9 of 13 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ | | | Lifting Ma Bell's Cloak Of Secrecy | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | A New Look At Basic Telephone Systems | | | | by VaxCat | | | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Though telephones predate radio communications by many years, they aren't nearly as simple as they appear at first glance. In fact, some aspects of telephone systems are most interesting and quite ingenious. In this file, I will describe some of these more interesting and perhaps less well-known areas of telephone systems. Before going any further, let me explain and apologize for the fact that some of the information in this file may not be altogether complete, up to date, or even totally correct. I do not work for any phone company, and therefore, I do not have unlimited access to internal telephone company literature. Moreover, there is very little material available in books or magazines which describes how United States telephone systems work. Much of the information in this file has been obtained piece-meal from many different sources such as books, popular magazines, computer data communications journals, handbooks, and sometimes just plain hearsay. I have tried to correlate as much as possible all the little bits and pieces into a coherent picture which makes sense, but there is no easy way to be sure of all the little details. So think of this article as if it is a historical novel - generally accurate and, regardless of whether it is completely true or not, fascinating. With this out of the way, let's go on. You, as a customer, are generally referred to as the "subscriber." Your telephone connects to the Central Office through a two-wire cable which may be miles long, and which may have a resistance on the order of hundreds or even thousands of Ohms. This cable is essentially a balanced line with a characteristic impedance of around 900 Ohms, but this varies greatly with different cables, different weather conditions, and different calls. This is why it is so hard to keep a hybrid phone-patch balanced. The main power in the central office comes from 48 volt storage batteries which are constantly kept trickle-charged. This battery is connected to your line through a subscriber relay and a balanced audio transformer. The relay is sensitive enough to detect even quite small currents through your line. The buttons which stick up out of your telephone case when you lift the handset activate the hook switch. The name probably dates back to the days when the handset (or even earlier, the earpiece) hung on the side of the phone from a hook. In any case, when your phone is hung up it is said to be on the hook, and when you lift the handset to make a call it is said to go off the hook. With the phone on hook, the line is connected only to the bell (called the ringer). Because the bell circuit has a capacitor in it, no DC current can flow through the phone. As a result, the subscriber relay back in the central office will be de-energized, indicating to the central office (let's abbreviate that as CO from now on) that your phone is hung up. Since there is no current through your line or phone, there is no voltage drop anywhere, and so if you measure the voltage across the phone line at your phone you will see the entire 48 volts (or even more if the CO batteries are well charged). The positive (grounded) lead is called the tip and the negative lead is called the ring; these names correspond to the tip and ring of a three-circuit phone plug. Now suppose you want to place a call; You pick up the handset and the phone goes off the hook. This completes the DC circuit through the dial, microphone, and the hybrid network which is basically a complicated transformer circuit. At this point current starts to flow from the battery through your line and phone, and the subscriber relay back at the CO pulls in. The line voltage across your phone now drops to just a few volts because the line is loaded down by the low resistance of the phone. The CO now searches for some idle dialing circuits, and when it finds them, connects a dial tone back to your phone. When you hear this, you start dialing. So lets talk about rotary dial, the type of phone which you turn with your finger (we will talk about Touchtone dials later). When you dial a number, the dial acts as a short circuit until you release the dial and let the built-in spring return it back to the resting position. As it is returning, it starts to open and close the circuit in sequence to indicate the number you dialed. If you dial a 1, it opens the circuit once; if you dial a 9 it opens the circuit nine times. As the dial is returning it cause the subscriber relay to open and close in step. This enables the CO to recognize the number you want. When you finish dialing, the dial becomes just a plain short circuit which passes current through the microphone and the hybrid network. Since the mike is a carbon unit, it needs this current to work. When the CO receives he complete number, it starts to process your call. If you dialed another subscriber in the same area, it may connect you directly to that subscriber's line. Calls to phones a little further away may have to be routed through another CO, while long distance calls may go through one or more long distance switching centers (called tandems) and possibly many other CO's before arriving at the destination. At the completion of this process, you may get either a ringing signal, indicating that the phone at the other end is ringing, one of several types of busy signals, or possibly just silence, if something goes wrong somewhere. When you talk to the person at the other end, the cable carries audio in both directions at the same time. Your carbon microphone varies the current in your circuit, and this current variation is detected by a balanced transformer in the CO. At the same time, audio coming back to your phone goes through the hybrid network to your earphone. In phone company lingo they like to call the mike a transmitter, and the earphone is called the receiver. You may be interested in the makeup of the various tones you may hear on your telephone; these tones are important to people such as computer communications designers who have to build equipment which will recognize dial or other signaling tones: Dial tone in older exchanges may still be a combination of 120 and 600 Hz, but the newer exchanges use a combination of 350 and 440 Hz. There is often a slight change in the DC line voltage at the beginning of dial tone, and this may also be detected. Busy signal is a combination of 480 and 620 Hz which alternates for 1/2 second on and 1/2 second off (i.e., 60 interruptions per minute) when the party you are calling is busy. The same busy signal may be used for other conditions such as busy interoffice or long distance circuits, but would then be interrupted either 30 times a minute or 120 times per minute. This is a standard agreed on by an international telecommunications organization called CCITT (and I don't offhand remember the French words it stands for), but occasionally other frequencies up to 2 kHz are used. A siren-like sound varying between 200 and 400 Hz is often used for other error conditions. The ringing tone, which you hear coming back to you when the phone rings on the other end of the connection, is nowadays mostly a combination of 440 and 480 Hz, but there is great variation between CO's. Very often a higher frequency such as 500 Hz is interrupted at 20 Hz, and other tones are used as well. The tone is usually on for 2 seconds and off for 4 seconds. The ringing current, actually used to ring the bell in a telephone, is an AC voltage since it has to activate a ringer which has a capacitor in series with it. Different companies use different ringing currents, but the most common is 90 volts at 20 Hz. Since a typical phone may be thousands of feet away from the CO, the thin wires used may have a fairly high line resistance. Hence only a relatively small current can be applied to the bell, certainly not enough to ring something like a doorbell. This problem is solved by making the bell resonant mechanically at the ringing frequency so that even a fairly small amount of power is enough to start the striker moving hard enough to produce a loud sound. This is the reason why a low-frequency AC is used. Although this raises some problems in generating a 20 Hz signal at a high enough voltage, it has the advantage that a bell will respond to a ringing current only if the frequency is quite close to the bell's naturally resonant frequency. If you build two bells, one resonant at 20 Hz and the other resonant at 30 Hz, and connect them together to the same line, you can ring just one bell at a time by connecting a ringing current of the right frequency to the line; this has some useful applications in ringing just one phone on a party line. Now let's look at some of the components of the phone itself. We will consider the most common new phone, a model 500 C/D manufactured by Western Electric and used by Bell System affiliated phone companies. This is the standard desk phone, having modern rounded lines and usually having a G1 or G3 handset. It was developed about 1950 and replaced the older 300-series phones which had the older F1 handset and had sharper corners and edges. There was an in between phone, where they took an old 300-series phone and put a new case on it which resembled the 500-style case, but had a straight up and down back - the back of the case came straight down right behind the handset cradle, whereas the true 500-style telephone has what looks like a set sticking out behind the cradle). If you are still in doubt as to which phone you have, the bell loudness control is a wheel on the 500-type phone and a lever on the 300-type. If you live in the boondocks, you may still have the 200-type phone (sometimes called the ovalbase) or maybe even the desk-stand type that looked like a candlestick, with the microphone mounted on the top and the earpiece hanging on the side from a hook. Neither of these phones had a built in bell, and so you probably have a bell box attached to your wall. If you have a phone with a handle on the side which you crack to call the operator, the following does not apply to your phone! Now lets discuss the bell circuit, which consists of a two-coil ringer and a 0.5 uF capacitor. On Western Electric phones the capacitor is mounted inside the network assembly, which also has a large number of screws on top which act as connection points for almost everything inside the phone. I have never been able to find out why the ringer has two coils of unequal resistance, but it app