From editor@telecom-digest.org Wed Sep 29 11:57:42 2004 Received: (from ptownson@localhost) by massis.lcs.mit.edu (8.11.6p3/8.11.6) id i8TFvg213594; Wed, 29 Sep 2004 11:57:42 -0400 (EDT) Date: Wed, 29 Sep 2004 11:57:42 -0400 (EDT) From: editor@telecom-digest.org Message-Id: <200409291557.i8TFvg213594@massis.lcs.mit.edu> X-Authentication-Warning: massis.lcs.mit.edu: ptownson set sender to editor@telecom-digest.org using -f To: ptownson Approved: patsnewlist Subject: TELECOM Digest V23 #455 TELECOM Digest Wed, 29 Sep 2004 11:56:00 EDT Volume 23 : Issue 455 Inside This Issue: Editor: Patrick A. Townson 3Com Unveils New Wireless Switch Products; Large-Scale, Secure (Solomon) Hackers Target Microsoft's JPEG Flaw (Monty Solomon) Calls to 711 (Deaf Message Service) Are Being Blocked (Jim Willis) Re: BART Cop Orders Radio Turned Off to Protect Trains (jdj) Re: BART Cop Orders Radio Turned Off to Protect Trains (Al Gillis) Re: BART Cop Orders Radio Turned Off to Protect Trains (Scott Dorsey) Re: Any Old Mechanical Systems Still in Use in the US? (Tony P.) Re: Any Old Mechanical Systems Still in Use in the US? (Fred Goldstein) Re: Any Old Mechanical Systems Still in Use in the US? (jdj) Re: What is the Name of #? How did # Get its Name? (Wesrock@aol.com) Re: No Call Ref ID in SS7/C7 Why? (Ariel Burbaickij) Re: What's Lurking In Your PC? (Scott Dorsey) All contents here are copyrighted by Patrick Townson and the individual writers/correspondents. Articles may be used in other journals or newsgroups, provided the writer's name and the Digest are included in the fair use quote. By using -any name or email address- included herein for -any- reason other than responding to an article herein, you agree to pay a hundred dollars to the recipients of the email. =========================== Addresses herein are not to be added to any mailing list, nor to be sold or given away without explicit written consent. Chain letters, viruses, porn, spam, and miscellaneous junk are definitely unwelcome. We must fight spam for the same reason we fight crime: not because we are naive enough to believe that we will ever stamp it out, but because we do not want the kind of world that results when no one stands against crime. Geoffrey Welsh =========================== See the bottom of this issue for subscription and archive details and the name of our lawyer; other stuff of interest. ---------------------------------------------------------------------- Date: Tue, 28 Sep 2004 23:59:35 -0400 From: Monty Solomon Subject: 3Com Unveils New Wireless Switch Products for Large-Scale, Secure 3Com Unveils New Wireless Switch Products for Large-Scale, Secure Enterprise Wireless Deployments MARLBOROUGH, Mass.--(BUSINESS WIRE)--Sept. 28, 2004-- 3Com Provides More Details on Blueprint for Integrating Wired and Wireless Networks; Interoperability Allows Enterprise Customers to Choose Best-of-Breed Wireless Deployments 3Com Corporation (Nasdaq: COMS) today announced product details of its new wireless switch solutions for enterprise customers. As part of 3Com's enterprise wireless "blueprint" and forming a complete enterprise wireless offering, the new 3Com(R) wireless switch solutions include an enterprise-class wireless switch, a large enterprise wireless controller, mobility system software, mobility management software and new managed access points (APs). These products combine together to provide higher levels of wireless security and mobility, simplified and centralized management of complex wireless LAN environments, higher network availability, fast roaming with quality of service (QoS) and class of service (CoS), standards-based deployment flexibility, and "pay as you grow" network scalability. - http://finance.lycos.com/home/news/story.asp?story=43898916 ------------------------------ Date: Wed, 29 Sep 2004 00:03:06 -0400 From: Monty Solomon Subject: Hackers Target Microsoft's JPEG Flaw NEW YORK (AP) -- In a harbinger of security threats to come, hackers have exploited a newly announced flaw in Microsoft Corp. programs and begun circulating malicious code hidden in images that use the popular JPEG format. Software tools to create the malicious images began appearing last month, and this week security experts saw images employing them posted on adult-oriented Usenet newsgroups. To get the malicious code, a visitor must download the image and view it using Microsoft's Windows Explorer software, said Oliver Friedrichs, senior manager with Symantec Security Response. - http://finance.lycos.com/home/news/story.asp?story=43917559 ------------------------------ Reply-To: Jim Willis From: Jim Willis Subject: Calls to 711 (Deaf Message Service) Are Being Blocked Date: Tue, 28 Sep 2004 23:56:40 -0400 I have read the digest off and on over the years and I have searched the archives and don't see this question right off. A deaf person moved into a care facility and they asked me to see what was up when they could not get the relay service. They pay $20.00 monthly for phone service that goes through a PBX/CENTREX -- (Dial 9 before number you are calling) Long distance is ok -- you will be billed for it as an incidental on your bill. If you dial 9-711 the call does not complete. All other long distance and local calls and toll free calls complete. Is this a common programming bug on PBX/CENTREX ? Has anyone run into this kind of thing before in the USA or CANADA ? Kind regards, Jim Willis - jwillis@drlogick.com ------------------------------ From: jdj Subject: Re: BART Cop Orders Radio Turned Off to Protect Trains Date: Tue, 28 Sep 2004 16:52:55 -0700 Organization: Posted via Supernews, http://www.supernews.com On Tue, 28 Sep 2004 18:22:36 +0000, Brian Inglis wrote: > On Mon, 27 Sep 2004 18:55:52 -0700 in comp.dcom.telecom, jdj > wrote: >> On Mon, 27 Sep 2004 02:55:18 +0000, Brian Inglis wrote: >>> fOn 25 Sep 2004 19:39:25 -0700 in comp.dcom.telecom, >>> hancock4@bbs.cpcn.com (Lisa Hancock) wrote: >>>> Never heard that. But I've heard to turn off cell phones while >>>> refueling the car, and I wonder if that's really necessary. >>> According to MythBusters, it's not; but opening the car door (e.g. to >>> get at a ringing cell phone) has caused incidents, either from static >>> electricity or the lighting circuit (haven't seen a definitive cause). >> MythBusters did not test this. Their test was something completely >> different: No vehicles or petrol pumps were involved. > They attempted to cause ignition/explosion of gasoline vapour by calling > a cell phone. Exactly. ------------------------------ From: Al Gillis Subject: Re: BART Cop Orders Radio Turned Off to Protect Trains Date: Tue, 28 Sep 2004 18:23:27 -0700 Organization: http://extra.newsguy.com > [TEELECOM Digest Editor's Note: Much snippage, then...) > to the terrorist his reward with all those virgins in heaven, etc. Oh! I thought it was lots of Virginians in heaven! I feel a lot better about it now! ------------------------------ From: kludge@panix.com (Scott Dorsey) Subject: Re: BART Cop Orders Radio Turned Off to Protect Trains Date: 29 Sep 2004 10:00:26 -0400 Organization: Former users of Netcom shell (1989-2000) Lisa Hancock wrote: > Years ago airlines wouldn't allow psgrs to use their transistor radios > onboard because it interfered with their navigation equipment. I > never understood how just listening to a radio could interfere with > other equipment, but this was a common standard restriction. I don't > know if it still applies today. It does. With FM radios it is a particularly serious problem, because of the way the superhet design works. The radio's front end has a local oscillator which operates either 10.7 MHz above or below the FM band. It mixes the adjustable local oscillator with the radio signal to form a difference frequency at 10.7 MHz which then goes into an intermediate frequency fixed receiver chain at 10.7 MHz. This means you get a lot of junk slightly above and slightly below the FM band floating around. And right above the FM band are the aircraft navigation frequencies, and then slightly farther up the VHF aircraft comm frequencies. Even a slight possibility of interference with these is a serious issue. Older cheap radios would leak a lot of LO signal and trash. Newer radios tend to use an IC front end that has somewhat less leakage just because the power level of the LO and mixer stage is so much less. > As to the claim BART radios were "special" years ago, there is > definitely truth to that. BART's original train control system > had many problems, including a train that ignored a stop signal > and flew off at a terminal into the parking lot. Whether silencing > radio receivers would make a difference I don't know, but it is a > fact BART had serious system problems and may have been very sensitive > about any perceived risk of interference, justified or not. BART had enough serious control system problems that radios were the least of their possible worries. But it's possible they may at one time have forbidden the use of two-way radios on board while they were trying to figure the problems out. It sounds to me just like a police officer who was trying to do his job but without any real understanding of the actual policy or the risks involved. But to be honest, I don't know the policy either. --scott "C'est un Nagra. C'est suisse, et tres, tres precis." ------------------------------ From: Tony P. Subject: Re: Any Old Mechanical Systems Still in Use in the US? Organization: ATCC Date: Tue, 28 Sep 2004 21:40:10 GMT In article , hancock4@bbs.cpcn.com says: > Stanley Cline wrote: >> The places where one would expect to find the last steps (Alaska bush >> country, small independents in general, etc.) actually went digital >> quite early on, largely because of things like environmental concerns >> (Redcom's MDX series switches, popular in extremely remote areas, are >> specifically built with harsh environments in mind) and human resource >> needs and in part because small independents' generally higher USF >> receipts compared to Bells and large indeps allowed for earlier >> conversion to digital. > What I was told that the superior remote maintenance facility of ESS > vs. electro mechanical was a big factor. AFAIK, when changing a > number or services for a customer, an office visit by a craftsman is > needed on electro mechanical to reroute wires from the distributing > frame. However, on ESS, that is all done electronically. Also, SxS > requires periodic maintenance since it is mechanical moving parts; ESS > does not. When a craftsman has to drive a considerable distance to > service something like that, the savings are significant. > Some other rural areas may not be as rural anymore and facing growth. > Going to ESS over SxS allows a bigger switch to fit in the same size > building, saving expensive building expansion. I wonder -- how often do the reed relays on the #1ESS need to be replaced? They are technically a mechanical device. We didn't get true digital until the #4ESS tandem and then the #5ESS gave us pure digital switch fabric for POTS services. Interestingly a properly configured #5ESS can also be a tandem too, as can the DMS switches by Nortel. In article , jdj@now.here says... > On Mon, 27 Sep 2004 12:44:51 -0700, Lisa Hancock wrote: >> Some other rural areas may not be as rural anymore and facing growth. >> Going to ESS over SxS allows a bigger switch to fit in the same size >> building, saving expensive building expansion. > Another advantage of the modern ESS, such as a 5E, is that the switch can > be spread around geographically. > The first I saw of this was a 5E used as a PBX. Parts of the switch were > in distant buildings. That increased line capacity enormously. > In the outskirts of this town, Pa Bell did not lay new cable with the > new housing. They just put the line and group cards in the field and > used the old telephone pairs for trunks. But things grew beyond the > normal capacity and instead of laying more cable or replacing copper > with fiber, they took the cheap way out and started using > pairgain. Very soon there will be too many new lines even for > pairgain. Maybe they'll figure out how to do DS3 over a copper pair by > then? > The only fiber out here now belongs to ATT Long Lines (or whatever > they call it now) and the cable company. > Modern switches also can handle multiple exchanges. Where mechanical > switches could handle only one exchange or prefix, the modern ESS can > take many more. The single 5E in town, where there was once two xbars, > handles eight LEC exchanges and at least three CLEC exchanges. Right now PRVDRIWADS2, a Northern Telecom DMS-100 here in Providence has 51 exchanges that it handles. It is also the access tandem for most of the surrounding communities. > Another nearby GTE city had a SxS and I would call into just to hear > it translate too. I would dial in with DTMF, which would be translated > to pulse + MF, then to pulse. Then there was that Continental > Telephone switch that let one hear it hunting for dialtone, translate > to and from DTMF, translate a toll number to a routing code, etc. One > could tell whether a called number was busy before the connection was > completed. I used to wish I lived there. > Don't get me started on old switches ... I remember when the Pawtucket, RI CO was on #5Xbar. That was a noisy beast. You could hear it doing everything. ------------------------------ Date: Tue, 28 Sep 2004 18:43:27 -0400 From: Fred Goldstein Subject: Re: Any Old Mechanical Systems Still in Use in the US? At 9/28/2004 05:40 PM, John Levine wrote: aside: John's picture ran large in today's Boston Globe! >> The single 5E in town, where there was once two xbars, handles eight >> LEC exchanges and at least three CLEC exchanges. > Really? I've heard of Bell handling switching for tiny independents > (VZ North for Naushon Island, for example), but I've never heard of a > LEC selling switching to a CLEC. I suppose this aspect of local competition isn't that well known, but indeed the way many competitive programs, including MCI's The Neighborhood, work is by using ILEC switching. This is called UNE Platform, when the ILEC provides the CLEC with all of the basic telephone service, at cost-based wholesale rates. Because the CLEC, not the ILEC, is the carrier of record (they're merely outsourcing components to the ILEC, albeit all of them), the CLEC gets the Switched Access revenue from the long distance providers. That's why it's so critical to nationwide long distance plans! And because local usage is on a cost, not tariff, basis, high "zone" and local charges don't apply -- so a UNE-P CLEC can afford to sell flat-rate local service in New York City, with no zone charges to the suburbs. UNE Platform began when the Democratic-majority FCC that first implemented the Telecom Act interpreted it to require incumbents to provide, as unbundled network elements, all of the elements used to provide Plain Old Telephone Service, as well as Centrex service. (Voice mail and DSL were not included.) This was challenged in court but the Supreme Court in 1998 upheld it. Thus the network elements included the local loop, the local switch, "shared" interoffice transport between the local switch and other switches in the local calling area, tandem switching, signaling, and operator service. So a lot of CLECs have set up shop to sell this. It has both good and bad aspects, depending perhaps on how you view them! UNEs are priced at a cost-based rate (a complex formula called Total Element Long Run Incremental Cost), without regard to ILEC tariff rates. So where ILEC margins are highest, the CLEC can sell UNE-P at a good margin and still undercut the ILEC. This annoys the ILECs to no end, though I think it potentially has the benefit of forcing the ILECs -- and their regulators -- to set their own prices closer to cost. UNE-P also lets a small CLEC sell service in places where they have too few customers to install any facilities of their own. (Without UNE-P, you can't break even as a facilities-based CLEC without a lot of lines in a give wire center. Too much common cost per CO.) So it brings competition to the sticks. But it isn't "true" competition, in the sense of using separate capital plant. It's physically a form of resale, and the ILECs don't like it. The current FCC chairman, Michael Powell considers that latter detail to be absolutely determinative, and he has resolved to kill UNE-P. It's still being fought out. Already, unbundled local switching is being limited to "retail", rather than "enterprise", in many areas, with a maximum of four lines per end user. That kills the UNE-P Centrex and PBX trunk (ISDN PRI and other T1) business. [TELECOM Digest Editor's Note: This system -- UNE-P -- is what our local telco, Prairie Stream Communications does. PAT] ------------------------------ From: jdj Subject: Re: Any Old Mechanical Systems Still in Use in the US? Date: Tue, 28 Sep 2004 16:57:42 -0700 Organization: Posted via Supernews, http://www.supernews.com On Tue, 28 Sep 2004 16:04:17 -0400, John R. Levine wrote: >> The single 5E in town, where there was once two xbars, handles eight >> LEC exchanges and at least three CLEC exchanges. > Really? I've heard of Bell handling switching for tiny independents (VZ > North for Naushon Island, for example), but I've never heard of a LEC > selling switching to a CLEC. Sorry, I should have clarified that it only handles routing for CLEC customers. No Bell wants a CLEC to use their switch. ------------------------------ From: Wesrock@aol.com Date: Tue, 28 Sep 2004 20:36:50 EDT Subject: Re: What is the Name of #? How did # Get its Name? In a message dated Mon, 27 Sep 2004 05:10:01 GMT Dave Thompson writes: > On Mon, 20 Sep 2004 13:51:34 +0000, bonomi@host122.r-bonomi.com > (Robert Bonomi) wrote: >> The 80-columns wide 'standard' for a video display is simply a >> reflection of the 80-column width of a standard punch-card. Because, >> in the 'commercial' environment, 'input' software *was* standardized >> at 80 columns -- directly attributable to the punch-card antecedents. >> Many early 'budget' video terminals for home/hobby use did *not* show >> 80 columns -- it was difficult to achieve that many characters across >> a standard TV receiver display -- > Right; see below. (Except they were mostly used locally and called > displays not terminals.) >> As to 'why punch cards were 80 columns', the answer is probably >> similar to "why railroad tracks are 4' 8-1/2" apart." Standard >> lettering for a _lot_ of business applications is 10 characters/inch. >> A punch-card is 8-1/2" wide. between the cut corner, and the rounded >> edge, you have just over 8" available for the printing on the >> top. Those who remember teletypewriter circuits, including TWX and Telex, will no doubt recognize: A QUICK BROWN FOX JUMPED OVER THE LAZY DOG'S BACK 1234567890 XX SENDING which among, other things, tested whether the TTY was correctly set for 80 columns and that the 80th column was not jammed. (Note that THE and A can be interchanged, but one must be THE and the other A.) (This test also determined that all characters of the alphabet were printing and that the shift-unshift function was working correctly.) The teletypewriter was in existence for several decades before computers, and its punched-tape technology was also well established. It was an ideal input-output device before punched cards and CRT displays took over. Wes Leatherock wesrock@aol.com ------------------------------ From: ariel.burbaickij@gmail.com (Ariel Burbaickij) Subject: Re: No Call Ref ID in SS7/C7 Why? Date: 29 Sep 2004 01:33:01 -0700 Organization: http://groups.google.com tls@panix.com (Thor Lancelot Simon) wrote in message news:: > In article , Ariel Burbaickij > wrote: > > tls@panix.com (Thor Lancelot Simon) wrote in message > news:: >> Excuse me but I do not see hop by hop nature as the main hurdle for >> defining unique call id. One obvious solution would be to include some >> number unique to the originating switch (its pointcode?) plus gmt plus >> some random value. > It's not a "hurdle", it's the reason there's no _need for_ a unique > call ID: because there is already a unique tuple identifying any call, > for the duration of that call: OPC, DPC, TCIC. Between any pair of switchs (on one leg) -- sure. How about the whole path? OPC/DPC can be reused in the national plane and CIC surely also. So unfortunately I would say even so they do identify one leg of call setup pretty unambigiously, this is not a replacement for end-to-end unique identifier. > This tuple is different between any pair of switches in the call > path, but because the standard makes very clear the ordering of the > messages (and message reordering is severely restricted) and the > transitions in the call state machine you can nonetheless follow a > call from A to Z through the network, using OPC, DPC, TCIC for every > pair of switches involved. Yes. You can do it without any doubt and standard SS7 diagnostic tools can do it also. But in my opinion they out of necessity utilize some kind oh heuristic that maybe gives you 99.9% of calls right but what about 0.01% one does care about most? I do not see any mecahnism in current ISUP that is 100% relaible replacement for call ref id. > I said current because it is present in B-ISUP very well. > Standard SS7 diagnostic tools, in fact, do exactly this. As I pointed > out in my earlier message, the treatment of the SLS field in most > national variants is intended, in point of fact, to make it easier to > catch the right messages for any call even when debugging with an > extremely simplistic protocol analyzer -- or even by hand (believe me, > I've done it). >> Not always ISUP is actually hop-by-hop as you surely know. ISUP over >> SCCP will give you end-to-end nature. > That depends what meaning, exactly, you put to "end-to-end". In > practice, even when run over SCCP, ISUP signaling is necessarily > logically hop-by-hop with the hops corresponding to the hops in the > actual voice path -- as it has to be, because *the trunks must be > allocated hop by hop* and that is exactly what ISUP does. Even if you > are running ISUP over SCCP, except in extraordinarily simple networks > (in other words, *not real world networks*) the calling party's end > office switch cannot know _a priori_ the entire path the call will > take through the network even if it could know the address of the > called party's end-office switch; so trunk signalling _can only_ > proceed hop-by-hop, which is what it does. Terribly sorry about it but I do not see the fact that path must be set hop-by-hop (as it must be set almost everywhere) as the reason for preclusion of call ref id tag in the setup message. >> Sure, for one link. What about debbuging which involves several >> switches. How are you going to guess which messages belong toghether >> in such an environment? > This is easy, and it's done all the time. You get into the links > between the switches in the call path and you find the messages in > ascending time order that have the right calling and called party ID > and that are in the right state in the call state machine (for > example, IAM and RLC will cascade through the network in an obvious > way). There are a few -- very few -- corner cases where things can > get a little tricky, but in practice the order of trunk allocation on > all major-vendor switches guarantees that you don't see them. > This is not rocket science. Telco personnel do it all the time, in > busy networks. Students in Telcordia protocol classes do it _by > hand_, which is tedious but entirely possible. Yes, I have done it myself and know that it works in the majority of the cases. Once again, are you sure that this mechanism always works relaibly? By reliable I mean something you can present in the court as the evidence should it be necessary. > Most good SS7 protocol analyzers do it automatically, for what it's > worth. Even the old HP sets that are often used as teaching tools > have features intended to help with this. I assure you, it works. > In practice, one very quickly zeroes in on a particular hop in the > call path when diagnosing SS7 or trunk troubles; so really, very > little time is spent trying to chasx calls end-to-end anyway. > You mention "ISUP over ISUP" as an example of end-to-end ISUP > signalling. With the exception of the incompletely-specified > pass-along message (PAM) that I referred to before, I'm not entirely > sure I know what you mean. Can you give me more details? It was not me, it was Phil ;-). I have never worked with PAM so I cannot say anything about it. I told about ISUP-over-SCCP only. > One thing that bears remembering about ISUP is that when it was > designed, compact encoding of messages was a major concern -- there > was serious grumbling already about the link upgrades that would be > required in order to handle the increases in message size compared to > the original CCIS that it replaced. Another thing to keep in mind is > that later protocols in the same protocol suite have much more in > common with computer data protocols of the mid 1980s (e.g. extensive > use of ASN.1 encoding) than with ISUP, which is really best understood > as a slight tweak of the rather ugly result of tearing CCIS apart into > two (or did I mean three? ;-)) layers for standardization. So > niceties that one expects from other protocols, e.g. an end-to-end > transaction ID, aren't likely to be there unless they're really > needed; and it's not tremendously surprising to me that in this case, > the judgment was that that feature was not. Well, the question is: was ISUP something like gap stopper or was it designed for years to come. If it was decided to upgrade despite all the grumbling I would try to do it right the first time (actually it was not first time at all), so that further upgrades are at least less painful. So to summarize: I still find the fact that ISUP does not have call ref id at least as very pity let us hope that this will not become essential short-coming under some circumstances. With Best Regards, Ariel Burbaickij > Thor Lancelot Simon tls@rek.tjls.com ------------------------------ From: kludge@panix.com (Scott Dorsey) Subject: Re: What's Lurking In Your PC? Date: 29 Sep 2004 10:16:23 -0400 Organization: Former users of Netcom shell (1989-2000) Monty Solomon wrote: > Because it's so new and still evolving, many computer users don't > understand spyware. Here's a quick tutorial to bring you up to date on > this insidious problem. > http://www.businessweek.com/magazine/content/04_40/b3902115_mz070.htm Although this article does briefly mention the advantage of going to a less popular browser, it neglects to mention that this is almost exclusively a problem related to IE, and it has entirely to do with hooks built into IE to allow remote execution. From Microsoft's standpoint, this is a feature and not a bug. Eliminating IE eliminates the problem. --scott "C'est un Nagra. C'est suisse, et tres, tres precis." ------------------------------ 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 networks such as Compuserve and America On Line, Yahoo Groups, and other forums. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. TELECOM Digest is a not-for-profit, mostly non-commercial educational service offered to the Internet by Patrick Townson. All the contents of the Digest are compilation-copyrighted. You may reprint articles in some other media on an occasional basis, but please attribute my work and that of the original author. Contact information: Patrick Townson/TELECOM Digest Post Office Box 50 Independence, KS 67301 Phone: 620-402-0134 Fax 1: 775-255-9970 Fax 2: 530-309-7234 Fax 3: 208-692-5145 Email: editor@telecom-digest.org Subscribe: telecom-subscribe@telecom-digest.org Unsubscribe:telecom-unsubscribe@telecom-digest.org This Digest is the oldest continuing e-journal about telecomm- unications on the Internet, having been founded in August, 1981 and published continuously since then. Our archives are available for your review/research. We believe we are the oldest e-zine/mailing list on the internet in any category! URL information: http://telecom-digest.org Anonymous FTP: mirror.lcs.mit.edu/telecom-archives/archives/ (or use our mirror site: ftp.epix.net/pub/telecom-archives) Email <==> FTP: telecom-archives@telecom-digest.org Send a simple, one line note to that automated address for a help file on how to use the automatic retrieval system for archives files. You can get desired files in email. ************************************************************************* * TELECOM Digest is partially funded by a grant from * * Judith Oppenheimer, President of ICB Inc. and purveyor of accurate * * 800 & Dot Com News, Intelligence, Analysis, and Consulting. * * http://ICBTollFree.com, http://1800TheExpert.com * * Views expressed herein should not be construed as representing * * views of Judith Oppenheimer or ICB Inc. * ************************************************************************* ICB Toll Free News. Contact information is not sold, rented or leased. One click a day feeds a person a meal. Go to http://www.thehungersite.com Copyright 2004 ICB, Inc. and TELECOM Digest. All rights reserved. Our attorney is Bill Levant, of Blue Bell, PA. ************************ DIRECTORY ASSISTANCE JUST 65 CENTS ONE OR TWO INQUIRIES CHARGED TO YOUR CREDIT CARD! REAL TIME, UP TO DATE! SPONSORED BY TELECOM DIGEST AND EASY411.COM SIGN UP AT http://www.easy411.com/telecomdigest ! ************************ --------------------------------------------------------------- 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 fifty 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. End of TELECOM Digest V23 #455 ******************************