|
|
Message Digest
Volume 28 : Issue 236 : "text" Format
Messages in this Issue:
Re: my future telephones
Re: my future telephones
Re: my future telephones
Re: my future telephones
Re: How Hackers Snatch Real-Time Security ID Numbers
Re: How Hackers Snatch Real-Time Security ID Numbers
Re: How Hackers Snatch Real-Time Security ID Numbers
Re: How Hackers Snatch Real-Time Security ID Numbers
VOIP codecs and interoperability (was "Re: my future telephones")
Re: VOIP codecs and interoperability (was "Re: my future telephones")
Texting (and cell phone usage) while driving movie: the consequences
Re: Texting (and cell phone usage) while driving movie: the consequences
Re: GSM-only interference
====== 27 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: Wed, 26 Aug 2009 01:56:48 -0400
From: Eric Tappert <e.tappert.spamnot@worldnet.att.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: my future telephones
Message-ID: <cgi9955dlgtvar9jp4ns0f7ipk9evbdhav@4ax.com>
On Tue, 25 Aug 2009 17:25:06 -0400 (EDT), Thad Floryan
<thad@thadlabs.com> wrote:
>> [...]
>> ****** Moderator's Note *****
>>
>> Please explain what "G.711u" means,
>
>Per http://www.voip-info.org/wiki/view/ITU+G.711:
>
>ITU G.711
>
>G.711 is a high bit rate (64 Kbps) ITU standard codec. It is the
>native language of the modern digital telephone network.
[Moderator snip]
>G.711 is supported by most VoIP providers.
The public switched telephone networks used circuit switching, so a
sample was transmitted every 125 microseconds and, because of circuit
switching, each sample had the same delay reaching the other end. The
major delay for VoIP networks is the packetizing delay, as multiple
bytes (samples) are included in each packet. Additionally a large
buffer is required at the receiving end to accommodate variable delay
in packet delivery due to the non-circuit switched network. This was
a big deal with ATM as the voice folks wanted very short packets and
the data folks wanted very long packets. In an IP network the data
guys won. The compression processing is not the big factor in
determining the delay between the two parties, the packetizing and
variable network delay is.
Having said that, who cares? The answer is in user tolerance to echo,
which will be present if one of the parties has a hybrid in the
circuit (there's one in every conventional phone set). User tolerance
to echo depends on two factors, the loudness and the delay. VoIP
always has a longer delay than the PSTN, thus echo is more of a
concern. If the round trip delay is long enough (satellite circuits
come to mind...), the delay itself becomes bothersome even in the
absence of echo.
In short, the need for a big buffer at the receive end to accommodate
variable packet delays and the packetizing process itself (which has
to accumulate multiple samples before transmitting) leave VoIP very
susceptible to delay issues, including echo problems. VoIP providers
often use various network "tricks", such as giving priority to voice
packets through routers, to minimize delay on voice circuits to
minimize these impairments.
Of course this is not to say that G.711 has better voice quality than
lower rate compression schemes. The standard measure is Mean Opinion
Score, which is a one to five scale of circuit quality based on user
testing. G.711 is the "gold" standard in these cases, with an MOS
greater than four, which the Bell System considered "toll quality".
Circuits with an MOS of 3 or so are usable, thus the heavy compression
of cell phones and VoIP circuits which have very short analog
sections.
ET
***** Moderator's Note *****
Thanks for your contribution. I can tell you've been "in the trenches"
of VoIP, so I'll add some more questions to my first.
1. Why does VoIP have to be delayed by packetization? Can't the
originating station simply send a lot of tiny packets?
2. I was told that ATM cells are sized to prevent echo entirely: is
that true? What is the "official" delay point at which humans
perceive echo?
3. What process is used to mark VoIP packets for priority? I had
thought that there wasn't any specification for minimum transit time
in the IP protocol, so if routers are able to identify VoIP traffic
and prioritize it, I'd like to know how it's being done.
4. What is the MOS of an ISDN BRI line? I ask because some users are
very sensitive to voice quality issues, and they tend to be much
better satisfied with ISDN connections than with POTS.
Bill Horne
------------------------------
Date: Wed, 26 Aug 2009 11:37:59 -0400
From: Eric Tappert <e.tappert.spamnot@worldnet.att.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: my future telephones
Message-ID: <daka955csmg63ac594ia1cbr1ds11p6qm5@4ax.com>
On Wed, 26 Aug 2009 10:40:04 -0400 (EDT), Eric Tappert
<e.tappert.spamnot@worldnet.att.net> wrote:
>On Tue, 25 Aug 2009 17:25:06 -0400 (EDT), Thad Floryan
><thad@thadlabs.com> wrote:
>
>>> [...]
>>> ****** Moderator's Note *****
>>>
>>> Please explain what "G.711u" means,
>>
>>Per http://www.voip-info.org/wiki/view/ITU+G.711:
>>
>>ITU G.711
>>
>>G.711 is a high bit rate (64 Kbps) ITU standard codec. It is the
>>native language of the modern digital telephone network.
>
>[Moderator snip]
>
>>G.711 is supported by most VoIP providers.
>
>The public switched telephone networks used circuit switching, so a
>sample was transmitted every 125 microseconds and, because of circuit
>switching, each sample had the same delay reaching the other end. The
>major delay for VoIP networks is the packetizing delay, as multiple
>bytes (samples) are included in each packet. Additionally a large
>buffer is required at the receiving end to accommodate variable delay
>in packet delivery due to the non-circuit switched network. This was
>a big deal with ATM as the voice folks wanted very short packets and
>the data folks wanted very long packets. In an IP network the data
>guys won. The compression processing is not the big factor in
>determining the delay between the two parties, the packetizing and
>variable network delay is.
>
>Having said that, who cares? The answer is in user tolerance to echo,
>which will be present if one of the parties has a hybrid in the
>circuit (there's one in every conventional phone set). User tolerance
>to echo depends on two factors, the loudness and the delay. VoIP
>always has a longer delay than the PSTN, thus echo is more of a
>concern. If the round trip delay is long enough (satellite circuits
>come to mind...), the delay itself becomes bothersome even in the
>absence of echo.
>
>In short, the need for a big buffer at the receive end to accommodate
>variable packet delays and the packetizing process itself (which has
>to accumulate multiple samples before transmitting) leave VoIP very
>susceptible to delay issues, including echo problems. VoIP providers
>often use various network "tricks", such as giving priority to voice
>packets through routers, to minimize delay on voice circuits to
>minimize these impairments.
>
>Of course this is not to say that G.711 has better voice quality than
>lower rate compression schemes. The standard measure is Mean Opinion
>Score, which is a one to five scale of circuit quality based on user
>testing. G.711 is the "gold" standard in these cases, with an MOS
>greater than four, which the Bell System considered "toll quality".
>Circuits with an MOS of 3 or so are usable, thus the heavy compression
>of cell phones and VoIP circuits which have very short analog
>sections.
>
>ET
>
>***** Moderator's Note *****
>
>Thanks for your contribution. I can tell you've been "in the trenches"
>of VoIP, so I'll add some more questions to my first.
>
>1. Why does VoIP have to be delayed by packetization? Can't the
> originating station simply send a lot of tiny packets?
>
>2. I was told that ATM cells are sized to prevent echo entirely: is
> that true? What is the "official" delay point at which humans
> perceive echo?
>
>3. What process is used to mark VoIP packets for priority? I had
> thought that there wasn't any specification for minimum transit time
> in the IP protocol, so if routers are able to identify VoIP traffic
> and prioritize it, I'd like to know how it's being done.
>
>4. What is the MOS of an ISDN BRI line? I ask because some users are
> very sensitive to voice quality issues, and they tend to be much
> better satisfied with ISDN connections than with POTS.
>
>Bill Horne
Bill,
The reason for the added delay due to packetizing is simply the length
of the packet requires multiple samples, thus they have to be
accumulated in a buffer before being sent. There is considerable
overhead in an IP packet, so short packets are undesirable as they
tend to use more bandwidth than longer packets for the same data
throughput.
ATM is a switched circuit technology with fixed length cells of 53
bytes, thus the packetization delay is only 48 samples or 6
milliseconds. This size packet is too short for relatively efficient
use of an IP network. The delay jitter to the far end is much less in
a switched circuit network where the packets (cells in this case)
always traverse the same path, so the receive bufffer can be shorter
(only a couple of cells). IP networks route each packet separately,
so there is no control over the transit time. The perception of echo
is a function of loudness and delay, very short delays are perceived
as sidetone and not considered an impairment. Generally echo control
devices are not used on circuits less than a few hundred miles in
length (I seem to recall 500 miles as the minimum for echo canceler
installation in the PSTN). On very long delays, the echo really gets
bothersome. The magic point is about 40 dB of echo return loss, then
echo ceases to be the issue and the delay in response from the other
side is the annoying factor on very long transit delays.
Unfortunately, G.711 codecs have a S/N of about 35 dB, so network echo
cancelers need some form of additional suppression (called the
non-linear processor...) that adds it's own impairments.
There are extensions to the IP protocol (like RSVP protocol) that
allow identification of traffic priority and VoIP providers usually
use them on their networks to minimize the delay jitter. They are
also necessary for video, BTW.
The advantage of BRI is that the circuit is "4-wire" from the origin,
thus there is no echo path due to hybrids in the non-existent analog
loop. Of course if the call connects to an analog loop, echo is still
a problem due to the reflections from the far end. In this case the
called party has no echo path (except the very short one from the
phone to the hybrid on the CO line card, which would be interpreted as
sidetone anyway,,,) but the BRI user would have an echo return from
the analog loop at the other end. On an ISDN to ISDN call, the
quality of service is generally controlled by the codec, which is
G.711 compliant, so that's the best you can get. Digital all the way
is the way to go...
As an aside, the military had a private network (AUTOVON) with 4-wire
loops (and phones) and no hybrids. The idea was to eliminate the echo
generation components so that circuits could be strung together in any
old fashion in wartime without regard to echo control.
Hope this helps.
ET
------------------------------
Date: Wed, 26 Aug 2009 18:46:25 -0400
From: "Geoffrey Welsh" <gwelsh@spamcop.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: my future telephones
Message-ID: <cb1d0$4a95bb5e$d8fedaf8$7621@PRIMUS.CA>
> ***** Moderator's Note *****
> 3. What process is used to mark VoIP packets for priority? I had
> thought that there wasn't any specification for minimum transit time
> in the IP protocol, so if routers are able to identify VoIP traffic
> and prioritize it, I'd like to know how it's being done.
At every point where packets are switched, they may be directed to a link
that is not idle, so outbound packets are queued. Using a variety of
mechanisms (including looking into the IP datagrams to see if you can
recognize attributes of time-sensitive protocols) forwarding devices MAY
choose to insert the datagram not at the end of the queue like most traffic
but at (or near) the front, minimizing added latency.
As Eric points out, since there is no guarantee that every datagram that
makes up a connection follows the same path, this does not eliminate jitter.
As people far wiser than I have pointed out, every network treats "quality
of service" features differently (or not at all), so you should not count on
any help when traversing the internet at large.
--
Geoffrey Welsh
.
------------------------------
Date: Wed, 26 Aug 2009 02:01:56 -0400 (EDT)
From: Dan Lanciani <ddl@danlan.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: my future telephones
Message-ID: <200908260601.CAA27199@ss10.danlan.com>
|****** Moderator's Note *****
|
|Please explain what "G.711u" means, and why you chose that option. I'd
|also appreciate you telling us how much it cost.
Others have covered G.711; I'll add only that my application is mostly
internal and even 10Mb/s Ethernet has plenty of capacity. Until very
recently my DSL was 768k/128k which is marginal for a single G.711
stream. Now that I have a whopping 1M/384k I may do more with
external VOIP.
The short answer to the cost question is that I spent way too much
money and an absurd amount of time getting things working to my
liking. You may recall I posted about some replacement firmware I
wrote for a multi-ring adapter. This was one of several significant
software exercises that were part of the effort.
Asterisk is of course free and I already had a machine on which to run
it. There were some bugs (one related to directed call pickup and the
others to the Festival speech synthesizer interface) that took me a
while to fix owing somewhat to my lack of familiarity with Asterisk's
structure. This was a rather disconcerting process because I found
references and voodoo workarounds for the symptoms of these bugs going
back years. I hope I was just unlucky to hit some unresolved problems
and this won't be an ongoing maintenance thing.
I decided to use my existing Cisco routers for POTS ports since I was
already familiar with the management interface. Initially I tried the
NM-HDA-4FXS module in my Cisco which (as the name implies) gives you 4
FXS ports. It also accepts add-in cards which can give you 8 FXO
ports. I wanted 5 FXO ports so this seemed like a good deal with
populated cards at $200-$300 on eBay.
Unfortunately, the NM-HDA FXO ports have two serious flaws. One flaw
is that when the router reboots the ports busy out the line until the
router comes back up. This is a bit of a safety concern and, of
course, the router may never come back up. I was able to "fix" this
problem by lifting the pins of the IC that was being used to busy the
line. It was busying as if it was a ground-start line so my
modification did not affect loop-start operation. The other flaw is
that CID reception is very unreliable. There seem to be both hardware
issues with signal level and firmware timing problems that are
unlikely to be fixed since there are newer interfaces available.
Having invested a fair bit of time in learning Cisco VOIP
configuration I decided to try a newer generation interface: VIC2-4FXO
(~$150) cards in NM-HD-2VE (~$100) carriers. These seem to work fine.
The related FXS interface (VIC-4FXS/DID) is ~$200. In retrospect I
could probably have done better with non-Cisco ports, but now that
everything is working...
Dan Lanciani
ddl@danlan.*com
------------------------------
Date: Wed, 26 Aug 2009 21:45:41 +1000
From: Colin <colins@swiftdsl.com.au>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: How Hackers Snatch Real-Time Security ID Numbers
Message-ID: <4a952067$1_1@news.peopletelecom.com.au>
hancock4@bbs.cpcn.com wrote:
> On Aug 25, 9:15 pm, David Clayton <dcs...@myrealbox.com> wrote:
[...]
> Another issue that needs discussion is the wide open connections to
> eastern Europe, where apparently a great deal of trouble originates.
[...]
Or it originates from someone in the west hijacking the eastern European (or Chinese) wide open PCs
to send the spam.
Colin
------------------------------
Date: Wed, 26 Aug 2009 15:14:16 +0000 (UTC)
From: danny burstein <dannyb@panix.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: How Hackers Snatch Real-Time Security ID Numbers
Message-ID: <h73jg7$kkr$1@reader1.panix.com>
In <4a952067$1_1@news.peopletelecom.com.au> Colin <colins@swiftdsl.com.au> writes:
>hancock4@bbs.cpcn.com wrote:
>> On Aug 25, 9:15 pm, David Clayton <dcs...@myrealbox.com> wrote:
>[...]
>> Another issue that needs discussion is the wide open connections to
>> eastern Europe, where apparently a great deal of trouble originates.
>[...]
>Or it originates from someone in the west hijacking the eastern European (or Chinese) wide open PCs
>to send the spam.
Or, of course, paying them for services.
While there's a lot of Fear Mongering about it, the "Russian
Business Network" certainly seems to be pretty ugly.
Wiki has a good initial writeup (but again, keep a bit of
a cynical eye open):
http://en.wikipedia.org/wiki/Russian_Business_Network
--
_____________________________________________________
Knowledge may be power, but communications is the key
dannyb@panix.com
[to foil spammers, my address has been double rot-13 encoded]
------------------------------
Date: Wed, 26 Aug 2009 12:09:04 -0500
From: pv+usenet@pobox.com (PV)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: How Hackers Snatch Real-Time Security ID Numbers
Message-ID: <95WdnUY4bJqt8QjXnZ2dnUVZ_odi4p2d@supernews.com>
Thad Floryan <thad@thadlabs.com> writes:
>It appears Macs have attracted the criminals' interest -- the new
>Snow Leopard release from Apple this coming Friday (Aug. 28) will
>have anti-virus/-malware software built in. Screen shot here:
And it stops all two of the circulating remote-access trojans. Wow! *
--
* PV Something like badgers, something like lizards, and something
like corkscrews.
------------------------------
Date: Wed, 26 Aug 2009 18:21:02 -0400
From: "Geoffrey Welsh" <gwelsh@spamcop.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: How Hackers Snatch Real-Time Security ID Numbers
Message-ID: <61857$4a95b56b$d8fedaf8$28047@PRIMUS.CA>
danny burstein wrote:
> It's really about time that people proposing this concept
> just stop a second and think before putting ink to paper.
> Or electrons to a screen.
OK, let's think about it: the same decision is made by people other than
malware writers every day, and the "concept" that you seem to be trying to
discredit is a very good predictor of outcome! For example, a former
employer sold software that interfaced with only one word processor which at
the time held dominating market share. When developers asked if he was
interested in integrating with another word processor with only niche market
share, he declined to make the investment. As market positions reversed, so
did word processor support. At no time was porting to the Mac or anything
UNIX-ish even discussed because their market share among prospective clients
was extremely low. Lots of software is prodiced for Windows only because
people act in accordance with the "concept."
Of course, not every developer writes exclusively (or at all) for Windows,
but if you want to know why malware authors never seem to choose anything
else you can't simply jump to the conclusion that the one and only reason is
the other platform's superior resistance. If someone writes a utility
useful for desktop publishing, they may choose to write it for the Mac
because the DTP market is reputed to have plenty of Macs... but, again, that
goes back to market share, doesn't it? Do any such factors carry weight (or
value) for malware writers? Well, maybe one: Mac owners may have more money
to steal, making it a more attractive platform for online banking password
theft...<grin>
> By this rationale, no one with an Audi should be able to find
> parts for their car.
... except that a significant number of people paid a premium price
(compared to, say, a Honda Civic or entry level Chevrolet) to own that car
and will pay a good price to have it repaired - and wouldn't buy the car at
all if there were no parts to repair it. Unless and until the criminals who
operate botnets, steal banking passwords, etc. discover that an infected Mac
is somehow worth more to them than an infected PC, they'll choose two (or
three, or four) infected PCs over one infected Mac every time.
> Somewhere between 5 and 10 percent of computers hooked
> up to the internet are Apples. Just about none of them
> have any sort of third party anti virus protection running.
>
> That's a pretty decent number of completely vulnerable
> systems, eh?
A "decent" number, yes. But still 1/10th to 1/20th the number of systems
you can target for a similar effort by choosing Windows over Mac. Even
taking into account your assertion that two thirds have some kind of
protection against malware and completely neglecting the fact that
signature-based malware recognition is dependent on updates so that a small
change in your code can bypass recognition (and discounting that update
subscriptions may expire and some of those Apples might still be
PowerPC-based or running OS 9), you're still facing a 30% of vulnerable
systems out there are Windows vs. 5-10% Mac OS.
If the effect is 3-6 times as much with Windows malware, even if there were
a difference in development effort, the cost/'benefit' balance is still
heavily in favour of trying to infect a PC. However, if you think about the
process of malware spreading, the imbalance is actually much higher... but
more about that later.
> So yes, you can have a Mac virus. But it ain't going
> to go very far.
Now let's think about that statement now that you've put electrons to
screen! Even given that it is more challenging to exploit a Mac, if it uses
an as-yet unpatched vulnerability it can still infect 100% of the Macs out
there!
However, we could (and should) also consider how malware spreads: if Mac
malware must find (connect to, email to, etc.) another Mac to spread and
only 5-10% of computers on the Internet are Macs, consider:
Mac told ten friends, who told ten friends, who told ten friends...
PC told thirty friends, who told thirty friends, who told thirty friends...
If your goal is to infect as many devices as possible (or, alternately, to
infect a given number as quickly as possible), then you just can't dismiss
market share as a driver of what platform the malware targets!
I believe this can be considered an application of Metcalfe's Law.
--
Geoffrey Welsh
.
------------------------------
Date: Wed, 26 Aug 2009 18:30:42 -0400
From: "Geoffrey Welsh" <gwelsh@spamcop.net>
To: redacted@invalid.telecom.csail.mit.edu
Subject: VOIP codecs and interoperability (was "Re: my future telephones")
Message-ID: <9722$4a95b7b0$d8fedaf8$32611@PRIMUS.CA>
Thad Floryan wrote:
> G.711 is supported by most VoIP providers.
VOIP noob question: if a VOIP provider is going to interoperate with an ILEC
(or other CLECs who have to interoperate with an ILEC), wouldn't the samples
have to be in G.711 format anyway? If so, wouldn't the question then be, do
we want to save on bandwidth over our 'internal' network and convert at the
interchange points, or to carry the data everywhere in that format for
convenience and give our customers the codec quality they've come to expect?
--
Geoffrey Welsh
.
------------------------------
Date: Wed, 26 Aug 2009 17:22:31 -0700
From: Thad Floryan <thad@thadlabs.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: VOIP codecs and interoperability (was "Re: my future telephones")
Message-ID: <4A95D1C7.90306@thadlabs.com>
On 8/26/2009 3:53 PM, Geoffrey Welsh wrote:
> Thad Floryan wrote:
>> G.711 is supported by most VoIP providers.
>
> VOIP noob question: if a VOIP provider is going to interoperate with an ILEC
> (or other CLECs who have to interoperate with an ILEC), wouldn't the samples
> have to be in G.711 format anyway? If so, wouldn't the question then be, do
> we want to save on bandwidth over our 'internal' network and convert at the
> interchange points, or to carry the data everywhere in that format for
> convenience and give our customers the codec quality they've come to expect?
My experience with VoIP is limited to asterisk; I didn't buy the Ooma
thing last month (money is tight).
For the systems I've setup, a PRI is ordered and run from the CO to
the client site. Here in California it's basically fiber now to a
wiring closet, then wire to the server room computer which has a PCI
card (model number escapes me, it's been a few years) that is the
client's endpoint of the PRI. Think of the PRI as a T1. So, yes, G.711
is used for the interface to the PSTN.
Internally to the client, I don't specifically know if G.711 is being
used -- it's a function of which instruments are on the VoIP LAN.
Cisco 7960 VoIP phones are typically used and their voice quality is
excellent even using a headset plugged in their backs.
Asterisk voice mail is saved in several formats, one of which is PCM,
and that sort-of implies G.711.
Looking right now at my old AT&T 3B1 manuals and the Voice Power
manuals (noting I still have 3 functional systems), it looks like
G.711 but I don't specifically see that nomenclature. Audio is sampled
at 64 kbps and it's definitely claimed as µ-law with no compression in
the Voice Power Programmer Applications Reference manual.
Hmmm, haven't looked at these manuals in awhile, and it almost appears
one can create a miniature CO with the 3B1s and the Voice Power cards
(with up to 7 Voice Power cards per 3B1).
------------------------------
Date: Wed, 26 Aug 2009 14:16:26 -0700
From: Thad Floryan <thad@thadlabs.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Texting (and cell phone usage) while driving movie: the consequences
Message-ID: <4A95A62A.6070408@thadlabs.com>
I wish there was a way to force all the [motorists] who use cell
phones and/or text while driving to view this [Public Service
Announcement]:
http://www.youtube.com/watch?v=5ttNgZDZruI [4 minutes 12 seconds]
Yes, it's brutal, and so are vehicular collisions and deaths caused
by distracted drivers.
***** Moderator's Note *****
Although the results may differ in the U.K. or in other countries,
ISTR that in the U.S., experience has shown that horrifying video
images don't have the intended result. I'll defer to other readers to
confirm or deny.
In any case, please remember that the video was not a documentary of
actual events: it is a work of fiction, and was professionally
produced as a Public Service Announcement. It was intended to frighten
young drivers with the hope of reducing traffic accidents, and it
should be viewed in that light.
Bill Horne
------------------------------
Date: Wed, 26 Aug 2009 19:37:49 -0700
From: Thad Floryan <thad@thadlabs.com>
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: Texting (and cell phone usage) while driving movie: the consequences
Message-ID: <4A95F17D.3000406@thadlabs.com>
On 8/26/2009 4:59 PM, Thad Floryan wrote:
> I wish there was a way to force all the [motorists] who use cell
> phones and/or text while driving to view this [Public Service
> Announcement]:
Bill (the moderator): thank you for 2 things. Cleaning up my
original words and reducing them to "[motorists]", and clarifying
what PSA means. I had no idea what was meant by PSA upon seeing it
in Silicon Valley's "Road Show Report" today at URL:
http://www.mercurynews.com/mrroadshow/
> http://www.youtube.com/watch?v=5ttNgZDZruI [4 minutes 12 seconds]
>
> Yes, it's brutal, and so are vehicular collisions and deaths caused
> by distracted drivers.
>
> ***** Moderator's Note *****
>
> Although the results may differ in the U.K. or in other countries,
> ISTR that in the U.S., experience has shown that horrifying video
> images don't have the intended result. I'll defer to other readers to
> confirm or deny.
I would think USA viewers have become inured to violence due to movies
and computer games moreso than in other countries. As a for example, in
the UK the BBFC censored the rat in the pink breathing fluid scene in the
movie THE ABYSS even though it was a crucial part of the plot.
> In any case, please remember that the video was not a documentary of
> actual events: it is a work of fiction, and was professionally
> produced as a Public Service Announcement. It was intended to frighten
> young drivers with the hope of reducing traffic accidents, and it
> should be viewed in that light.
I would add: it reflects what happens locally (Silicon Valley) on an almost
daily basis. Cell phone and texting related accidents are legion here. I see
anywhere from 5 to 20+ near-accidents daily -- it's incredible the carnage
isn't greater.
------------------------------
Date: Wed, 26 Aug 2009 19:33:06 -0500
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: redacted@invalid.telecom.csail.mit.edu
Subject: Re: GSM-only interference
Message-ID: <0o2dnUZLVazfSQjXnZ2dnUVZ_hFi4p2d@posted.nuvoxcommunications>
In article <h6pqcr$5mg$1@reader1.panix.com>,
>
>****** Moderator's Note *****
>
>You could measure either average or peak power density; the question
>is "Is GSM more likely to cause interference to audio devices, and if
>so, why?"
>
>It may be that GSM signals are clocked at an audible rate, so that
>devices that aren't shielded are creating audible signals.
*BINGO* The signal pattern has an 'envelope' component that hits the
audio spectrum.
Better shielding of the 'affected' devices *IS* the answer.
------------------------------
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 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.
The Telecom Digest is currently being moderated by Bill Horne while
Pat Townson recovers from a stroke.
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 (13 messages)
******************************
|
or 