Pat, the Editor

27 Years of the Digest ... founded August 21, 1981

Classified Ads
TD Extra News

Add this Digest to your personal   or  

 
 
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) ******************************

Return to Archives**Older Issues