Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id JAA26281; Thu, 2 Apr 1998 09:24:26 -0500 (EST) Date: Thu, 2 Apr 1998 09:24:26 -0500 (EST) From: editor@telecom-digest.org Message-Id: <199804021424.JAA26281@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V18 #50 TELECOM Digest Thu, 2 Apr 98 09:24:00 EST Volume 18 : Issue 50 Inside This Issue: Editor: Patrick A. Townson FBI Asks FCC to Resolve Wiretapping Dispute (Monty Solomon) Re: New LM-IMS-NANPA Planning Letters! (Mark J. Cuccia) Re: NYS (Bell Atlantic) to Get 'Per Activation' 3-way Calling (Reed) Re: Wireless Overlays are *Impossible* in the U.S. (Nils Andersson) Re: Wireless Overlays are *Impossible* in the U.S. (Fred R. Goldstein) Re: Browse the Web Undercover (Derek Balling) Re: Browse the Web Undercover (Andrew Green) Re: Browse the Web Undercover (Lee Winson) Re: Telephone Acoustic Interface (Jack Daniel) Re: Telephone Acoustic Interface (Peter Corlett) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * telecom-request@telecom-digest.org * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-727-5427 Fax: 773-539-4630 ** Article submission address: editor@telecom-digest.org ** Our archives are available for your review/research. The URL is: http://telecom-digest.org They can also be accessed using anonymous ftp: ftp hyperarchive.lcs.mit.edu/telecom-archives/archives (or use our mirror site: ftp ftp.epix.net/pub/telecom-archives) A third method is the Telecom Email Information Service: Send a note to archives@telecom-digest.org to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ************************************************************************* In addition, a gift from Mike Sandman, Chicago's Telecom Expert has enabled me to replace some obsolete computer equipment and enter the 21st century sort of on schedule. His mail order telephone parts/supplies service based in the Chicago area has been widely recognized by Digest readers as a reliable and very inexpensive source of telecom-related equipment. Please request a free catalog today at http://www.sandman.com --------------------------------------------------------------- Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. Please make at least a single donation to cover the cost of processing your name to the mailing list. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- Date: Tue, 31 Mar 1998 02:21:09 -0500 From: Monty Solomon Subject: FBI Asks FCC to Resolve Wiretapping Dispute Begin forwarded message: Date: Fri, 27 Mar 1998 14:44:23 -0800 (PST) From: Declan McCullagh Subject: FC: FBI asks FCC to resolve wiretapping dispute ******* WASHINGTON, March 27 (Reuters) - The FBI on Friday asked the Federal Communications Commission to resolve its bitter dispute with the telephone industry over changes to the U.S. phone system needed to allow future wiretapping. Telephone equipment makers and carriers have so far resisted implementing the FBI's interpretation of the 1994 Communications Assistance for Law Enforcement Act (CALEA) fearing they would have to spend billions of dollars to alter their systems. In a 67-page filing with the FCC, the FBI and Department of Justice contended that the industry's proposed standard to meet their wiretapping needs was "seriously deficient." Unless the industry is forced to change its standard, "information that is critical to public safety and law enforcement will be lost," the agencies wrote. Phone companies have said they plan to make their own filing with the FCC, asking the agency to reject the FBI's demands and extend a looming October deadline contained in the 1994 law. A senior Justice Department official said the agency would oppose the industry's move to extend the October deadline for meeting all requirements of the law. [...] ------------------------ WASHINGTON (AP) - Law enforcement officials asked the Federal Communications Commission on Friday to resolve a dispute with the telecommunications industry over preserving their ability to tap telephone lines in the digital age. In a petition filed with the FCC, the Justice Department and FBI asked the regulatory agency to come up with a solution to the long-standing dispute by Sept. 28. The cellular phone industry welcomed the petition. "It will be helpful to the industry, which had been trapped," said Cellular Telecommunications Industry Association spokesman Jeff Nelson, referring to the stalemate with law enforcement over a plan. The FCC, Nelson said, will weigh all points of view before taking any action and "we think that's a good place to be." The United States Telephone Association, which represents local phone companies, had no immediate comment. A 1994 law requires telecommunications companies to make digital wiretapping technology available to law enforcers. But after three years of negotiations, the telecommunications industry and the government have not been able to agree on a plan for doing that. One point of contention is what technical changes telecommunications companies must make to ensure that phones and other communications can be tapped legally as digital technology replaces the analog technology that has long been in use. Another is the cost of doing this and how much the government and the industry would pay. The telecommunications industry and privacy groups have accused law enforcers of trying to broaden their wiretapping powers, something the Justice Department and the FBI have denied. [...] ---------------------------------------------- POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to majordomo@vorlon.mit.edu with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ ---------------------------------------------- [TELECOM Digest Editor's Note: Poor FBI ... my heart really bleeds for them, doesn't yours? Not content to use the tremendous power they have already to snoop into the lives of Americans and wreak havoc at the snap of their fingers -- the constitution be damned and all that -- they want still more facilities available to them? Somehow they will survive, I am sure. Maybe they could just get a law passed requiring everyone to have a pad of those 'message for you' forms by each telephone. Whenever a call was placed or recieved, each party would be required to use one of those forms to summarize who called, their phone number and what the call was about. Then once a month forward all those forms to the local FBI office for review. PAT] ------------------------------ Date: Tue, 31 Mar 1998 16:43:54 -0600 From: Mark J. Cuccia Subject: Re: New LM-IMS-NANPA Planning Letters! LM-IMS-NANPA's website is updated as of Tuesday 31-Mar-1998, with TWO new Planning Letters! http://www.nanpa.com/planning_letters/planning_letters.html The two new ones are in Adobe-Acrobat .pdf format, and are: PL-NANP-117, Overlay of NPA 303 Colorado, with NPA 720 http://www.nanpa.com/pdf/pl-nanp-117.pdf Local ten-digit permissive dialing began on 1-Feb-1998 Mandatory ten-digit local dialing to begin on 1-June-1998, along with the beginning of new overlaid 720-NXX c/o codes. Test Number (to become available on 18-Apr-1998): 720-200-0000 PL-NANP-118, Split of NPA 702 Nevada, with NPA 775 http://www.nanpa.com/pdf/pl-nanp-118.pdf Clark County (includes Las Vegas) will retain NPA 702 Everything else will split to NPA 775 The three Nevada*Bell wire/ratecenters and their NXX's in Nye County in the southern (Pahrump) NV LATA (#721): Pahrump, Beatty, Lathrop Wells - will change to NPA 775. Two Nevada*Bell wire/ratecenters and their NXX's in Clark County (also in the southern/Pahrump NV LATA, #721): Indian Springs and Sandy Valley - will remain in NPA 702. All of Sprint/Centel and Moapa Valley Telco in Clark County, and in the southern/Pahrump LATA #721 will remain in NPA 702. Bordering towns in Nevada, such as Spirit Mountain NV (served out of the Phoenix AZ LATA #666) and Mesquite NV (served out of the Utah LATA #660), which are in Clark County... will retain NPA 702. Everything else in Nevada, whether in Nevada*Bell's northern/Reno NV LATA #720, or served from bordering states, such as: Jarbidge, Jackpot, Owyhee, Mountain City (all in LATA 652 southern ID) and Wendover (NV) served from Utah LATA #660. There are numerous rate/wirecenters in Nevada which are 'independent', as well as growing wireless, and even CLECs. An interesting sidenote... The five Nevada*Bell (Pacific*Telesis) wire/ratecenter/NXXs in LATA #721 (southern/Pahrump NV) have LATA-access tandem-homings, intra-LATA toll (via traditional LEC), and intra-LATA operator service tandem homings via _NOT_ any Nevada/Pacific*Bell tandem, but rather via an _INDEPENDENT_, Sprint-Centel! (all three tandem functions under: LSVGNVXB41T, 702+055+ (the northern/Reno LATA #720 tandem is: RENONV1274T, 702+020+, soon to be 775+020+) There _ARE_ a few areas in the US where a _BELL_ end-office has toll/ tandem homings (at least for intra-LATA, LATA-access, and LATA-opr) on an _independent_ telco! Unfortunately, the Pac/Nevada*Bell supplied info for the PL for Nevada might have some conflicting info as to which 702-NXX codes and rate/wirecenters remain in NPA 702 and which change over to NPA 775. Permissive dialing of either NPA for the splitting off region will begin on 12-December-1998; Mandatory use of NPA 775 for the splitting off region will start on 15-May-1999. The test number (which is supposed to become active on 14-Nov-1998) is 775-550-0775, which is typical of Pac/Nevada*Bell test number formats. It probably will come from the Nevada*Bell tandem in Reno. NWORLASKCG0 (BellSouth #1AESS Class-5 Local "Seabrook" 504-24x-) NWORLAIYCM1 (BellSouth-Mobility Hughes-GMH-2000 Cellular-MTSO NOL) NWORLAMA0GT (BellSouth DMS-100/200 fg-B/C/D Accss-Tandem "Main" 504+) NWORLAMA20T (BellSouth DMS-200 TOPS:Opr-Srvcs-Tandem "Main" 504+053+) NWORLAMA04T (AT&T #4ESS Class-2 Toll 060-T / 504-2T "Main" 504+) JCSNMSPS06T (AT&T #5ESS OSPS:Operator-Services-Tandem 601-0T 601+121) MARK_J._CUCCIA__PHONE/WRITE/WIRE/CABLE:__HOME:__(USA)__Tel:_CHestnut-1-2497 WORK:__mcuccia@mailhost.tcs.tulane.edu|4710-Wright-Road|__(+1-504-241-2497) Tel:UNiversity-5-5954(+1-504-865-5954)|New-Orleans-28__|fwds-on-no-answr-to Fax:UNiversity-5-5917(+1-504-865-5917)|Louisiana(70128)|cellular/voicemail- ------------------------------ From: Reed Subject: Re: NYS (Bell Atlantic) to Get 'Per Activation' 3-way Calling Date: Tue, 31 Mar 1998 15:47:11 -0700 Here in US West area, per-call 3-way was turned on without the users being told/warned. Result was users being billed $.75 whenever they hit the switchhook too fast to hangup on first call and make another (normal) call. Need to wait on-hook approx. 2 seconds. Otherwise same/similar rates and options. (Issue got big play on local news after the fact as complaints poured in...) Danny Burstein wrote: > From the "notice of proposed tariff", found in the {NY Daily News}, > 25-Mar-1998. > Notice is hereby .... effective April 12, 1998... > Customers have the option to subscribe (on a monthly > flate rate), ... or use Usage Threeway Calling on a > per-activation basis. > > Residence Business > Per activation: $0.75 $0.75 > Monthly cap: $6.00 $7.50 ------------------------------ Date: Tue, 31 Mar 1998 17:58:09 -0500 From: nilsphone@aol.com (Nils Andersson) Organization: AOL http://www.aol.com Subject: Re: Wireless Overlays are *Impossible* in the U.S. In article , Telecom@LincMad.NOSPAM (Linc Madison) writes: > Anyone who wants to argue that we should proceed with wireless > overlays must first address the question of how you can reconcile the > conflict with Local Number Portability issues. You are of course right as far as it goes. Those who advocate wireless overlays would of course have to concede that you cannot have number portability between the two types of service, although you could have portability within each. Very few if any people have even that portability now, and I am not holding my breath. I can just imagine me calling PBMS and asking them for a subscription using my old LACellular number. They would either a) not understand me at all or b) laugh at the notion. As to landline, I am not aware of any real alternative to GTE where I live, with ANY numbering scheme. Regards, Nils Andersson ------------------------------ Subject: Re: Wireless Overlays are *Impossible* in the U.S. From: fgoldstein@bbn.NO$LUNCHMEAT.com (Fred R. Goldstein) Organization: GTE Internetworking - BBN Technologies Date: Tue, 31 Mar 1998 20:37:10 GMT In article , Telecom@LincMad.NOSPAM says... > However, a frequent reader of this forum pointed something out to me > in private e-mail: wireless overlays are not only contrary to current > policy, but also impossible on a technical level! > The reason is quite simple: one of the underpinnings of Local Number > Portability is that you can change your service to *ANY* carrier while > keeping your existing number. That specifically *INCLUDES* wireless > carriers. Thus, you can force all existing wireless customers to change > to the new wireless overlay, but they can then turn around, order a POTS > line, and then convert the POTS number to the wireless service under LNP. That's an unnecessarily literalistic interpretation. Sure, you can't have a wireless-only overlay and PROHIBIT wireless users from being in the original NPA. But so what? How many wireless users will want to be in the original? Most cell phones are on a pay-for-airtime basis, so the owners don't want to be that easy to reach. Those who do, can. Cell phone carriers and other radio common carriers can get their own prefix codes now, so they can get new codes in the overlay while being allowed use of the other NPA for those who really care about it. They don't like being changed because reprogramming a cell phone takes some effort, but of course overlays prevent splits so it's sort of a wash. Nore to the point, I have a better (IMnsHO) idea. The overlay should be used for bulk number users, including wireless users who don't request otherwise. So Direct Inward Dialing (DID) blocks will go into the overlay, but if somebody *wants* a block of non-overlay numbers, there's a premium price. If you get a phone book listing, you can have a non-overlay -- this leaves out pagers, most cell phones, DID blocks, fax server blocks, etc. Again, if anyone WANTS to opt out of the overlay, there's a small price -- even a quarter a number a month will be enough to move most bulk-number users, other than those who have an interest in staying. This scheme is nondiscriminatory, since unlisted (and second) residence numbers also will need to pay the extra quarter to stay out of the overlay, while wireless users get the same choice. And of course the remaining codes need to be administered carefully, along with number portability so CLECs can have non-overlay numbers too. (Number conservation goes along with this, including splitting prefix codes within a rate center among carriers by block-of-1000.) Fred R. Goldstein k1io fgoldstein"at"bbn.com GTE Internetworking - BBN Technologies, Cambridge MA USA +1 617 873 3850 Opinions are mine alone; sharing requires permission. ------------------------------ From: Derek Balling Subject: Re: Browse the Web Undercover Date: Tue, 31 Mar 1998 08:25:48 -0600 Organization: SpeedChoice Monty Solomon wrote: > If you work in a large office or corporation and connect to the Web > via a T1 line, you're probably protected by a proxy server -- like > Netscape Proxy Server or Microsoft Proxy Server -- or a firewall. But > if you aren't covered by that kind of protection, you should check out > The Anonymizer, a public proxy server at www.anonymizer.com. > The Anonymizer serves as a surrogate for you, retrieving as many Web > pages as you wish from as many sites as you wish. It displays the > pages you request in a frame, so you know when it's working. If you're > using Anonymizer's free service, your browser window will display ads > and there is a 30-second delay. Another version does the job without > ads or delays for a quarterly fee of $15. Paying for Anonymizer's > service, or using a free personal proxy server like Lucent's > Personalized Web Assistant (see "Fight Back!" page 136) are the best > ways to browse incognito all the time. > In addition to keeping your e-mail address from nosy servers, > Anonymizer's proxy service keeps your ISP's name private and the URL > of the page you visit before you've clicked on the site. Anonymizer > also maintains your anonymity during FTP sessions and disables Java. It always amazes me how people are worried about a few disjointed sites putting together their web-travel habits, yet they're perfectly willing to place a LOT of trust in people they don't know and tell them ALL their travel habits. Some things to keep in mind with "Anonymizer" services: 1.) They see EVERYTHING you do. If you're reading your hotmail through an anonymizer, the people who run the anonymizer could very well have logged every single bit of it, because it had to go to them FIRST to proxy it back to you. 2.) They can develop MUCH better detailed travel pattern summaries than the average disjointed information most sites can. They know that "this IP address" went from My Yahoo, to My Excite, to C|Net, and wherever. How much would it be worth to an advertiser to be able to know the last 10 sites you visited before getting to where you are now, and offer you a product based on that info? Just some things to think about ... [TELECOM Digest Editor's Note: It is sort of odd that he tells us not to trust various web sites we know nothing about with information which is stored on our browser then at that same time tells us it is perfectly okay to pass all our traffic -- allowing a much better idea of who/what we are and are interested in -- to be handed over to some other unfamiliar site for processing. I still opt for what should be the easiest solution of all. Put some anonymous and incorrect details in your browser ID, do not use the mail programs offered by the browser, and on a regular basis keep the cookie and history files cleaned out. PAT] ------------------------------ From: Andrew Green Subject: Re: Browse the Web Undercover Date: Tue, 31 Mar 1998 08:56:02 -0600 > Regarding the mail program in Netscape, since I > do not use Netscape to get mail, I just left that blank all the time > but you could put totally dummy information there also. While I have my doubts about a few of the statements made in that article, it might be more revealing in terms of learning who can lift what out of the Netscape program if you were to set up a free account somewhere such as Hotmail, and plug that address into your Netscape Identity fields instead. Check the account periodically for signs of activity to see who's been sniffing your machine, if any. Andrew C. Green (312) 853-8331 Datalogics, Inc. email: acg@datalogics.com 101 N. Wacker, Ste. 1800 http://www.datalogics.com Chicago, IL 60606-7301 Fax: (312) 853-8282 ------------------------------ From: lwinson@bbs.cpcn.com (Lee Winson) Subject: Re: Browse the Web Undercover Date: 1 Apr 1998 00:08:19 GMT Organization: The PACSIBM SIG BBS > Your browser is selling you out. Without your knowledge, it's offering > up personal information to marketers who are only too happy to bombard > you with product offers, ads, and golden opportunities to make money Was there a web site that returned whatever info your browser was sending to it, so you see what was being released? Thanks. ------------------------------ From: Jack Daniel Subject: Re: Telephone Acoustic Interface Date: Sat, 28 Mar 1998 07:26:20 -0800 Organization: EarthLink Network, Inc. Reply-To: JackDaniel@RFSolutions.com Miguel Garcia wrote: > I'm developing a system which must communicate via telephone DTMF. As > many people know there must be a licence to connect anything directly > to the phone line in many countries such as mine. > Because of that I decided to use an acoustic interface. It uses one > microphone to receive voice, DTMF and to detect 400Hz signal (for call > progress status indication), and a second microphone is used for ring > detection (+- 3KHz in my telephone). A speaker is used to send > pre-recorded voice and DTMF signals from the system. > My problem is: > Although the ring detection (3KHz from the second microphone) and > 400Hz detection (from the first microphone) signals are both filtered > by two 4th order band pass filter (tuned on their adequate > frequencies) there are many frequencies in the natural environment > that cross (or are equal to) those tuned frequencies. > That way an interrupt request (to answer a call) can be falsely > generated into the system by the ring detection subsystem. > I think it will be worst in what concerns to the 400Hz detection > because, for example, if the system wants to dial a number, it takes > up the receiver with a controlled electromagnetic arm and it must to > recognise a dialing tone trough the first microphone of +- 400Hz. > The probability of confusion between this telephone sound and another > sound with the same frequency that may be present at the same > environment, at the same time, and captured by the microphone is high, > so the system may interpret it as dialing tone when it isn't present. > Of course it may misunderstand other telephone tones like ringing > tone, engaged tone ... > My question is: > Have you any idea about any resolution of this problem? Miguel, You have a classic tone decoder design problem. It sounds like you have a suitable filter for the 400 Hz decoder, but be as frequency selective as practical. The remaining domains you have to work with are amplitude and duration (time). In general terms, the decoder will respond faster as the input level increases to the ppoint of limiting or clipping. If your circuit allows the local voice to appear at the decoders input, place a notch filter in the outbound voice path. The loss of 400 Hz will not normally be significant in voice communications. This will reduce local 'talk-off' of the decoder. Next, integrate the output of the decoder detector so that it takes a long tone period to operte the output of the decoder. This is usually nothing more than a capacitor and resistor "RC" charge delay circuit. (Add a reverse diode if you want fast reset between tones) The nonger you can make the detection period, the less voice talk-off you will have because voice seldom holds a single frequency for very long. Obviously, if the decoder recieves a false tomne that is of the correct frequency and duration, it will not know the difference. That is why most designers use two simultanious non-harmonic tones for reliable tone burst signalling. Voice will not normaly operate a simultaneous two tone decoder. Thats how DTMF also works. There are at least two other additional possibilities: a. Add a syllabilic rate detector, which only has an output when the input frequency is NOT a balanced waveform like a tone. Its a sophisticated 'voice' modulation decoder. Use the output of the syllibilic rate detector to INHIBIT the 400 Hz decoders output. Therefore, the 400 Hz won't react if voice is also present. b. Use other forms of output inhibition based on other timing or level conditions inherent in the system that you have not described here. I hope this helps you. I'm sure more experienced (or inexperienced and over educated) people will have comments, arguements, spelling corrections and gramatical corrections. Jack Daniel ------------------------------ From: abuse@verrine.demon.co.uk (Peter Corlett) Subject: Re: Telephone Acoustic Interface Date: 01 Apr 1998 11:07:05 +0100 Organization: The Haunted Fishtank Miguel Garcia wrote: > I'm developing a system which must communicate via telephone DTMF. As > many people know there must be a licence to connect anything directly to > the phone line in many countries such as mine. My sympathies if this is really the case. I recall that you can connect items to the phone network provided it is CE marked, so if you can get your device CE tested and marked, this is probably the way to go. This is a result of EU legislation, and for example allows UK users who are generally overcharged for ISDN equipment to import cheap kit from Germany instead. [...] > I think it will be worst in what concerns to the 400Hz detection because, > for example, if the system wants to dial a number, it takes up the > receiver with a controlled electromagnetic arm and it must to recognise a > dialing tone trough the first microphone of +- 400Hz. The probability of > confusion between this telephone sound and another sound with the same > frequency that may be present at the same environment, at the same time, > and captured by the microphone is high, so the system may interpret it as > dialing tone when it isn't present. I'd suggest using a notch filter as well to eliminate 400Hz, and you can use the result of that to decide what the ambient noise is like. > Of course it may misunderstand other telephone tones like ringing tone, > engaged tone ... More filters... > My question is: > Have you any idea about any resolution of this problem? If you need lots of filters, I'd recommend the use of a cheap DSP rather than lots of discrete components. DSPs are designed for this sort of application, and can perform filtering very easily. In addition, it can generate and decode the DTMF, and may well be able to replace the microcontroller (if any) you were using, dependent on its workload. ------------------------------ End of TELECOM Digest V18 #50 *****************************