The Telecom Digest for October 03, 2010
Volume 29 : Issue 265 : "text" Format
Messages in this Issue:
====== 28 years of TELECOM Digest -- Founded August 21, 1981 ======
Telecom and VOIP (Voice over Internet Protocol) Digest for the
Internet. 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, and other stuff of interest.
Date: Fri, 01 Oct 2010 12:23:23 -0700
From: Thad Floryan <thad@thadlabs.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Uptime and lifetime of #5ESS
Message-ID: <4CA6352B.2040802@thadlabs.com>
One of the computer groups I moderate is the Yahoo "linux"
group. I recently began a thread about ksplice, a method
of updating the kernel while it's running and not requiring
a reboot.
The following copy'n'pasted lines are from an article appearing
in that thread this morning and I thought it worth sharing since
I learned something new from it; author's name is at the end:
> > [...]
> > How do you think telephone switching offices are upgraded?
>
> Interesting... I'd always assumed that (at least in modern
> situations)
> they had redundant backups and were just switched as they would in a
> failover scenario...
During normal operation, when a fault is detected things are a
little more complex than that. Normally the system is running a
hot backup with two systems running side by side, in lockstep,
with a "matcher" between them comparing the results of their
calculations. In the event that a mismatch (indicating a fault)
occurs a "fault isolation" program fires up and determines which
unit has failed. The system is then reconfigured so that the
faulty unit is cut out and the two systems share the good one. A
diagnostic program then is run on the faulty unit, the failing
circuit board identified, and a message is printed on the
maintenance console to replace that board. Once a new board has
been inserted the diagnostic is rerun and, if it passes, the
system is reconfigured to use the repaired unit for one side of
the system (going back to the normal configuration).
How effective is this strategy? The specifications for the #5
ESS (Electronic Switching System) require no more than 2 seconds
of down time over the design lifetime of the system -- 40
years. The last statistics I saw indicated that the systems were
actually accumulating less than 1 second of down time over that
40 year period. As I recall, diagnostic and fault recovery
software comprise about 2/3 of the code in the system.
> switch everything from the primary unit to the
> backup, upgrade the primary, switch traffic back and then
> upgrade the backup... or something along those lines...
In essence, that is what the retrofit process does. An important
part of the process, though, is translation of any data in memory
from the format in the old generic to that in the new generic,
and not losing any in-progress information during the switch
over. Upgrading the other processor is then a normal memory
mirroring operation (unless the upgrade included hardware changes
as well).
> Pretty neat though. Honestly, the more I hang out with the kernel
> guys and hear them talk about it, the more I'm being converted (or
> at least, more accustomed to the idea)
>
> >> Then again, maybe it's just my curmudgeonness...
> >
> > No, just lack of experience! :-) :-)
>
> Haven't heard someone tell me that in a long time :-) heh... but
> yeah, or at least ignorance... thanks for the bit of info though...
> pretty neat!
A good while ago the Bell System Technical Journal had an issue
devoted to the #5 ESS (#5 Electronic Switching System) that you
might find interesting.
Rich Strebendt
Date: Fri, 1 Oct 2010 15:47:31 -0400
From: Monty Solomon <monty@roscom.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: You can no longer rely on encryption to protect a BlackBerry
Message-ID: <p06240808c8cbeb2b3686@[192.168.180.244]>
You can no longer rely on encryption to protect a BlackBerry
A Russian passcode-breaker firm exploits a weakness in RIM's
encryption to crack open backups
By Martin Heller | InfoWorld
OCTOBER 01, 2010
http://www.infoworld.com/t/mobile-device-management/you-can-no-longer-rely-encryption-protect-blackberry-436
Date: Fri, 01 Oct 2010 16:38:58 -0700
From: Sam Spade <sam@coldmail.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Delivery of ANI on a non-IN WATS call?
Message-ID: <h-ednTrBQfWO7DvRnZ2dnUVZ_oednZ2d@giganews.com>
Sam Spade wrote:
> I was of the impression that the FCC's standing order on Caller ID
> required the originating LEC to honor a caller's request for
> non-delivery of Caller ID if the caller either preceded the call with
> *67 (1167) or had line blocking provided by the LEC.
>
> The exceptions are 911 call centers and calls to IN-WATs numbers, but in
> those cases it is actually ANI that is delivered, not CPN; to 911
> centers for obvious reasons and to IN-WATs subscribers on the premise it
> is a "collect" call.
>
> My local cable televsion company as an ordinary directly number. When I
> call they state (automated voice) they have my number. I don't have
> line blocking so I am not surprised. But, I decided to test it so I
> called again but with *67 first. Yep, the automated voice still had my
> number. I tested my *67 to another number in my residence and it works
> fine.
>
> Anyone have any idea if there is an exception for cable television
> companies for calls to their ordinary (billable) directory numbers?
>
> People are concerned about privacy these days. This seems like a big
> breach of the expectations of telephone subscribers.
>
Follow-up (and I should have figured this out) AT&T is indeed setting
the privacy flag when I precede my call to my cable company. But, the
cable company operates an LEC (DMS-500) as well as a cable television
company. It is them that is not honoring the privacy flag for calls to
their money office. Rather shabby, and all-too-typical of the corporate
arrogance we sadly see these days.
I filed an informal complaint with the California PUC, but I am not
holding my breath.
Date: Fri, 01 Oct 2010 16:44:21 -0700
From: Thad Floryan <thad@thadlabs.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: iPhone applications privacy issues
Message-ID: <4CA67255.2070304@thadlabs.com>
iPhone Applications & Privacy Issues: An Analysis of Application
Transmission of iPhone Unique Device Identifiers (UDIDs)
http://www.pskl.us/wp/?p=476
In 1999, Intel released its newest CPU - the Pentium 3.
Each processor included a unique serial number, visible
to any software installed on the system. A product
backlash quickly developed as privacy rights groups
realized that this serial number could be used to track
users' online behavior. The industry, along with trade
groups and governments, blasted this new feature; many
governments went as far as proposing legislation to ban
the use of Pentium 3 CPUs. Following the outcry, Intel
quickly removed the serial number feature from their
processor line, never to be re-introduced.
Fast forward a decade to the introduction of Apple's
iPhone platform. Much like the Pentium 3, devices running
the Apple iPhone operating system (IOS), including Apple
iPhones, iPads, and iPod Touches, feature a software-
readable serial number - a "Unique Device Identifier,"
or UDID. In order to determine if the privacy fears
surrounding the Pentium 3 have manifested themselves on
the iPhone platform, we studied a number of iPhone apps
from the "Most Popular" and "Top Free" categories in
Apple's App Store. For these applications, we collected
and analyzed the data being transmitted between installed
applications and remote servers using several open source
tools. We found that 68% of these applications were
transmitting UDIDs to servers under the application
vendor's control each time the application is launched.
Furthermore, 18% of the applications tested encrypted
their communications such that it was not clear what
type of data was being shared. A scant 14% of the
tested applications appear to be clean. We also
confirmed that some applications are able to link the
UDID to a real-world identity.
The iPhone's UDID is eerily similar to the Pentium 3's
Processor Serial Number (PSN). While the Pentium 3 PSN
elicited a storm of outrage from privacy rights groups
over the inherent risks associated with the sharing of
such information with third parties, no such concerns
have been raised up to this point regarding the iPhone
UDID. As UDIDs can be readily linked to personally-
dentifiable information, the "Big Brother" concerns
from the Pentium 3 era should be a concern for today's
iPhone users as well.
The full report is available here:
http://www.pskl.us/wp/wp-content/uploads/2010/09/iPhone-Applications-Privacy-Issues.pdf
Date: Fri, 1 Oct 2010 21:20:10 -0400
From: Monty Solomon <monty@roscom.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Turn an iPod into an iPhone
Message-ID: <p0624080cc8cc38a6f28d@[192.168.180.244]>
Turn an iPod into an iPhone
David Pogue
SEPTEMBER 30, 2010, 1:35 PM
There's some big news about Line2, the iPhone app I reviewed in March.
...
http://pogue.blogs.nytimes.com/2010/09/30/turn-an-ipod-into-an-iphone/
Date: Fri, 1 Oct 2010 21:23:00 -0400
From: Monty Solomon <monty@roscom.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: A Simple Swipe on a Phone, and You're Paid
Message-ID: <p0624080dc8cc39962b0d@[192.168.180.244]>
A Simple Swipe on a Phone, and You're Paid
By DAVID POGUE
September 29, 2010
It's always thrilling when somebody looks at the Way Things Have
Always Been Done, and then asks: Why?
And then goes on to change the world forever.
1967: Why is it necessary to wait in line for a human teller if all
you want to do is withdraw cash?
1974: Why shouldn't your document on the computer screen look the
same way it will when it's printed?
1991: If shampoo always settles to the bottom of the bottle, why is
the cap on top?
Recently, a San Francisco company has been asking an equally
groundshaking question: Why can't everyone accept credit cards?
Look, credit cards are great. There's a paper trail, there's fraud
protection, there's incredible convenience - just swipe and go. But
why is it that only companies accept them?
Why can't we use them to pay the piano teacher, the baby sitter, the
lawn-mowing teenager, even first graders at their lemonade stand? Why
aren't credit cards accepted at garage sales, food carts and PTA bake
sales? Heck, when your tipsy buddy wants to borrow $20 for a cab
home, why can't you eliminate the awkwardness and future conflict by
just running his Visa card on the spot?
...
http://www.nytimes.com/2010/09/30/technology/personaltech/30pogue.html
***** Moderator's Note *****
It won't work.
Businessmen take credit cards because their customers insist on using
them, and because the card fee is offset by the costs of handling,
counting, and safeguarding cash.
Ordinary people don't trust banks, and they don't trust credit cards:
not when they're on the receiving end.
Bill Horne
Moderator
Date: Fri, 1 Oct 2010 21:44:12 -0400
From: Monty Solomon <monty@roscom.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Lone $4.1 Billion Sale Led to 'Flash Crash' in May
Message-ID: <p06240810c8cc3bfaba6a@[192.168.180.244]>
Lone $4.1 Billion Sale Led to 'Flash Crash' in May
By GRAHAM BOWLEY
October 1, 2010
It was a stock market mystery that had everyone guessing for months:
just what caused that harrowing flash crash last May?
On Friday, after months of investigation and speculation, federal
authorities finally provided the answer: it all began with the click
of a computer mouse in Kansas.
In a long-awaited report on one of wildest days in Wall Street's
history, regulators said that the automated sale of a large block of
futures by a mutual fund - not named in the report, but identified by
officials as Waddell & Reed Financial, of Overland Park, Kan. -
touched off a chain reaction of events on May 6. The Dow Jones
industrial average plunged more than 600 points in a matter of
minutes that day and then recovered in a blink.
The finger-pointing and speculation that followed - Were high-speed
traders behind it? A rogue computer program? Financial terrorists? -
captivated Wall Street. But in the report released on Friday, the
authorities said they found no evidence of market manipulation.
Instead, the temporary crash resulted from a confluence of forces
after a single fund company tried to hedge its stock market
investment position legitimately, albeit in an aggressive and abrupt
manner.
The mutual fund started a program at about 2:32 p.m. on May 6 to sell
$4.1 billion of futures contracts, using a computer sell algorithm
that over the next 20 minutes dumped 75,000 contracts onto the
market, even automatically accelerating its selling as prices plunged.
The regulators hope the report lifts the uncertainty that has hung
over the nation's exchanges - and investors' minds - since the crash.
Certainly, officials at the Securities and Exchange Commission and
the Commodity Futures Trading Commission seemed confident they had
established the causes of the crash and answered any final doubts,
and the findings were welcomed by some in the markets.
But it also left lingering questions among many who felt it did not
explain why the crash took place on that particular day in May, or
provide any assurance that this could not occur again.
...
http://www.nytimes.com/2010/10/02/business/02flash.html
Date: Fri, 1 Oct 2010 21:44:12 -0400
From: Monty Solomon <monty@roscom.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: In a Computer Worm, a Possible Biblical Clue
Message-ID: <p0624080fc8cc3aff7f93@[192.168.180.244]>
In a Computer Worm, a Possible Biblical Clue
By JOHN MARKOFF and DAVID E. SANGER
September 29, 2010
Deep inside the computer worm that some specialists suspect is aimed
at slowing Iran's race for a nuclear weapon lies what could be a
fleeting reference to the Book of Esther, the Old Testament tale in
which the Jews pre-empt a Persian plot to destroy them.
That use of the word "Myrtus" - which can be read as an allusion to
Esther - to name a file inside the code is one of several murky clues
that have emerged as computer experts try to trace the origin and
purpose of the rogue Stuxnet program, which seeks out a specific kind
of command module for industrial equipment.
Not surprisingly, the Israelis are not saying whether Stuxnet has any
connection to the secretive cyberwar unit it has built inside
Israel's intelligence service. Nor is the Obama administration, which
while talking about cyberdefenses has also rapidly ramped up a broad
covert program, inherited from the Bush administration, to undermine
Iran's nuclear program. In interviews in several countries, experts
in both cyberwar and nuclear enrichment technology say the Stuxnet
mystery may never be solved.
There are many competing explanations for myrtus, which could simply
signify myrtle, a plant important to many cultures in the region. But
some security experts see the reference as a signature allusion to
Esther, a clear warning in a mounting technological and psychological
battle as Israel and its allies try to breach Tehran's most heavily
guarded project. Others doubt the Israelis were involved and say the
word could have been inserted as deliberate misinformation, to
implicate Israel.
...
http://www.nytimes.com/2010/09/30/world/middleeast/30worm.html
Date: Fri, 1 Oct 2010 21:44:12 -0400
From: Monty Solomon <monty@roscom.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Another Wireless PC-to-TV Idea
Message-ID: <p06240814c8cc3ea15975@[192.168.180.244]>
Another Wireless PC-to-TV Idea
By PAUL BOUTIN
September 23, 2010, 6:39 AM
Watching Internet video on your living room TV shouldn't be hard. The
stuff already plays on your laptop, so why not just connect your
laptop to your TV? A new $99 gadget called Veebeam, introduced a few
days ago, promises to make that easy to do.
I haven't had a chance to test Veebeam personally, but the product
comes with a pedigree. The VP of marketing, Patrick Cosson, has a
track record of hot consumer gadgets, first with the Squeezebox music
player and then with the Vudu TV console that plays movies on demand.
Veebeam is a video player designed for simplicity rather than piling
on the features. The idea is: If it plays on your PC, it plays on
your TV.
...
http://gadgetwise.blogs.nytimes.com/2010/09/23/another-wireless-pc-to-tv-idea/
Date: Sat, 02 Oct 2010 13:51:37 +1000
From: David Clayton <dcstar@myrealbox.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Slow down, take time to make the moment last
Message-ID: <pan.2010.10.02.03.51.36.288566@myrealbox.com>
A lesson for some of us, maybe?
http://www.theage.com.au/business/slow-down-take-time-to-make-the-moment-last-20101001-16179.html
Slow down, take time to make the moment last
Marcus Padley
October 2, 2010
I am in Bali. A BlackBerry and iPhone-free zone for the Padley family. Not
by decree but by choice. Our mobile phones have burbled a couple of times
in the room safe but I'll be buggered if we're letting anyone chase us
around out here.
If you've ever been surfing at Echo Beach at sunset, you'll appreciate
that there are times when the leash on your ankle is enough. Time with the
family and oneself is possibly the most valuable time of the year without
someone else's agenda disrupting it.
But still some of my fellow guests seem glued to the outside world. An
electronic leash on their ear. Glad I'm not married to you.
I was once impressed with the out of office email message of one of my
previous editors. It informed emailers that "I am out of the office until
January 12th. When I return, I will delete my whole inbox. If your message
was important send it again when I'm back.''
(more in the article)
--
Regards, David.
David Clayton
Melbourne, Victoria, Australia.
Knowledge is a measure of how many answers you have, intelligence is a
measure of how many questions you have.
Date: 2 Oct 2010 03:15:41 -0000
From: John Levine <johnl@iecc.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Delivery of ANI on a non-IN WATS call?
Message-ID: <20101002031541.29228.qmail@joyce.lan>
In article <lYWdnR99_an8hzvRnZ2dnUVZ_vadnZ2d@giganews.com> you write:
>I was of the impression that the FCC's standing order on Caller ID
>required the originating LEC to honor a caller's request for
>non-delivery of Caller ID if the caller either preceded the call with
>*67 (1167) or had line blocking provided by the LEC.
Nope. It sets a do-not-display flag that is supposed to be
interpreted by whatever does the displaying, which I suppose is the
terminating switch on POTS and either the switch or the phone on ISDN
sets.
If Comcast sees your number, it's because their switch isn't paying
attention to the do-not-display flag.
R's,
John
Date: Fri, 1 Oct 2010 10:30:37 -0700 (PDT)
From: markjcuccia@yahoo.com
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: 873 was a Typo (Re: Area Code Exhaust)
Message-ID: <8c3de57d-d5dd-473f-8e45-1ac5e868b5ea@a19g2000yql.googlegroups.com>
On Friday 01 Oct 2010, Mark J Cuccia wrote in reply to Joe Singer:
[ ... ]
> The outer neighberhoods within the "City" in area code 773 had
> completely exhausted its 773-NXX office codes back in 2007. The
> business district (The Loop) in area code 312 (there was that 312/773
> split back in Fall 1996) still has NUMEROUS office codes available
> for assignment.
>
> In Fall 2007, the new 872 (USA) area code officially overlaid BOTH
> 773 AND 312, even though there were still numerous 312-NXX office
> codes that could still be assigned. Even today, with code reclamation
> (or "voluntary returns" if there is ever really such a thing), the 773
> area code has a total of four 773-NXX codes now available for
> (re)assginment. But since the new 873 area code has been opened up as
TYPO... 873 is NOT the overlay to Chicago's 312 & 773: 872 (as noted
at the beginning of the paragraph) is.
873 is rather the pending (June 2013) overlay to 819 that covers
northern, western, and south-central Quebec (Canada), situated BETWEEN
418/581 and 450/579, the latter overlay pair originally being 514, the
514 NPA being the immediate Montreal PQ Metro area, having shrunk down
during 1998 when 450 split off. 514 (Montreal Metro) was also overlaid
with 438 back in 2006/07. 450 in southwestern Quebec was overlaid with
579 this past Summer 2010, and 418 for eastern Quebec (including
Quebec City) was overlaid wtih 581 in September 2008.
[Moderator snip]
Mark J. Cuccia
markjcuccia at yahoo dot com
Date: 1 Oct 2010 14:26:15 -0400
From: kludge@panix.com (Scott Dorsey)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Texting bans may add risk to roads
Message-ID: <i85947$nar$1@panix2.panix.com>
David Clayton <dcstar@NOSPAM.myrealbox.com> wrote:
>On Wed, 29 Sep 2010 21:42:59 +0800, John Mayson wrote:
>
>> According to the article...
>> "Texting bans haven't reduced crashes at all," says Adrian Lund,
>> president of the Insurance Institute for Highway Safety, whose research
>> arm studied the effectiveness of the laws.
>>
>Banning things like that only have a marginal effect on fools that think
>that they are entitled to do whatever they feel like regardless of any
>downside to others, that sort of law will only discourage the law-abiders
>who probably were a low risk factor anyway.
This is true, it really does nothing to prevent accidents. BUT, it gives
something else that people can be charged with when they cause an accident,
increasing the total penalties for the behaviour.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Date: Fri, 1 Oct 2010 12:30:03 -0700 (PDT)
From: markjcuccia@yahoo.com
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Delivery of ANI on a non-IN WATS call?
Message-ID: <3bcec8ee-8257-400f-9822-f0e4066ab995@j18g2000yqd.googlegroups.com>
On 01-Oct-2010, Sam Spade wrote:
> I was of the impression that the FCC's standing order on Caller ID
> required the originating LEC to honor a caller's request for
> non-delivery of Caller ID if the caller either preceded the call with
> *67 (1167) or had line blocking provided by the LEC.
>
> The exceptions are 911 call centers and calls to IN-WATs numbers, but in
> those cases it is actually ANI that is delivered, not CPN; to 911
> centers for obvious reasons and to IN-WATs subscribers on the premise it
> is a "collect" call.
>
> My local cable television company as an ordinary directly number. When I
> call they state (automated voice) they have my number. I don't have
> line blocking so I am not surprised. But, I decided to test it so I
> called again but with *67 first. Yep, the automated voice still had my
> number. I tested my *67 to another number in my residence and it works
> fine.
>
> Anyone have any idea if there is an exception for cable television
> companies for calls to their ordinary (billable) directory numbers?
>
> People are concerned about privacy these days. This seems like a big
> breach of the expectations of telephone subscribers.
Is your cable-TV company also a telco (CLEC)? If so, then they ARE a
telephone company, and as such, have access to C-ID info at their own
switch, even for per-line suppressed originating C-ID, as well as
*67/11-67 prefix per-call suppressed originating C-ID.
Remember that "per-line" and *67/11-67 per-call "blocking" isn't
really completely "blocking" SS7-delivered C-ID, at least not between
(SS7-capable) c.o.switches/trunks, but only suppressing it from actual
delivery over the final loop to the end-customer. Telcos (and possibly
even PBX systems of "non-telco" companies) can easily pickup ANY
(delivered) C-ID on incoming calls to their business offices, even if
the calling customer has "per-line" or *67/11-67 per-call "blocking"
(actually suppression) to the far-end.
And it's also likely possible that the cable-TV company, _also acting
as a CLEC_, has access to any ANI info delivered as well.
Mark J. Cuccia
markjcuccia at yahoo dot com
TELECOM Digest is an electronic journal devoted mostly to telecom-
munications topics. It is circulated anywhere there is email, in
addition 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 Bill Horne. 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.
The Telecom Digest is moderated by Bill Horne.
Contact information: Bill Horne
Telecom Digest
43 Deerfield Road
Sharon MA 02067-2301
781-784-7287
bill at horne dot net
Subscribe: telecom-request@telecom-digest.org?body=subscribe telecom
Unsubscribe: telecom-request@telecom-digest.org?body=unsubscribe telecom
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
Copyright (C) 2009 TELECOM Digest. All rights reserved.
Our attorney is Bill Levant, of Blue Bell, PA.
---------------------------------------------------------------
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 The Telecom Digest (14 messages)
|
| |
or 