30 Years of the Digest ... founded August 21, 1981
The Telecom Digest for January 20, 2012
====== 30 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 Bill Horne 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 that person, or email address
Addresses herein are not to be added to any mailing list, nor to be sold or given away without the explicit written consent of the owner of that address. 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: Thu, 19 Jan 2012 07:18:10 -0800 (PST) From: HAncock4 <firstname.lastname@example.org> To: email@example.com. Subject: Re: The Save Our Political Assets act Message-ID: <firstname.lastname@example.org> On Jan 18, 3:14 pm, Bill Horne <b...@horneQRM.net> wrote: > I was just looking down a page of Google search results, and mentally > drawing lines through the ones that pointed to Wikipedia, since it is > offline today to protest the Stop Online Piracy Act, a.k.a. SOPA. Philadelphia Inquirer editorial of Thursday, 1/19/2012: "The virtual world shows its real-time clout: After the Wikipedia- driven Internet blackout Wednesday, it's a safe bet that every high school student with an overdue homework assignment is well clued in to the debate over regulating online piracy. To say the protest went viral would be like characterizing the bubonic plague as a common cold. It was all but unavoidable online - from the black placard placed across Google's home page to the estimated 7,000 other sites that sought in some way to raise awareness." for full editorial please see: http://goo.gl/8n3Dt
Date: Thu, 19 Jan 2012 17:26:08 -0500 From: "Geoffrey Welsh" <email@example.com> To: firstname.lastname@example.org. Subject: Re: English Wikipedia anti-SOPA blackout Message-ID: <cd72d$4f189839$adce4530$28431@PRIMUS.CA> > ***** Moderator's Note ***** > [...] I support Wikipedia's decision to oppose SOPA. I hope you will, too. I was hoping that they - and many others - would consider implementing a permanent block of access from IP addresses assigned to Congress. Yes, I know that's not a simple as it sounds, but even an imperfect implementation would force many on Capitol Hill to use circumvention techniques in order to access some of the internet's content. ***** Moderator's Note ***** That's a great idea. I'd expand it to have Google delete all search results that point to the Congress, or (better yet) redirect them to public-interest sites that expose some massive pork barrel in the relevant district. Bill Horne Moderator
Date: Thu, 19 Jan 2012 16:46:02 -0500 From: "Geoffrey Welsh" <email@example.com> To: firstname.lastname@example.org. Subject: Re: Ringing Finally Ended, but There's No Button to Message-ID: <9ef9c$4f188f4d$adce4530$31583@PRIMUS.CA> tlvp wrote: > On Sun, 15 Jan 2012 08:58:55 -0500, Barry Margolin wrote: >> RTFM? Of an iPhone? > No, no, not of the iPhone, silly -- of the concert hall! Every > printed program, in every concert hall I've attended in this 21st > century, has stated, plainly and clearly, that patrons are requested > to turn their cell phones, pagers, and beepers OFF for the duration > of the concert. I have to admit that I never turned my Motorola KRZR (or its predecessor RAZR) off in such situations... but it was simple enough and I knew it well enough that I could make it silent or vibrate quietly so that no one else knew that it was alerting me. I now carry a Blackberry (no, I didn't finally cave under the shame of being a computer/data guy with a mere feature phone and no connectivity outside the home/office, it came with the work I am doing now) and I have to admit that I have yet to truly understand all the sources of alerts on it: phone calls, texts, email, "visual voice mail", Blackberry Messenger, events, reminders, apps... and something called level 1. Each of these have a combination of sound and vibration in each of several different alert profiles and, after weeks of using the phone, I think I'm done configuring one profile. I'm continually discovering Blackberry features - mostly by Googling things I want to do. The little bits of paper that came with the phone aren't nearly large enough to form even the cover of a comprehensive printed manual. So, no, I'm not surprised that your average Joe doesn't know everything his smartphone does. (Or maybe we can all just learn a lesson and switch our phones off when asked to.)
Date: Thu, 19 Jan 2012 16:18:10 -0500 From: "Geoffrey Welsh" <email@example.com> To: firstname.lastname@example.org. Subject: Re: Some unanswered questions from January 2011 Message-ID: <2755e$4f1888cf$adce4530$30287@PRIMUS.CA> Garrett Wollman wrote: >  It was obviously stupid to use TCP for multimedia applications. I was intrigued by that statement. [Garrett] mentions discarding list UDP packets, which might be fine in an uncompressed media stream, but aren't errors/omissions likely to cause disruption to a compressed media stream (for comparison, consider that data compression was only commonly implemented in dialup modems on top of error correction)? Or is the 'compression' implemented in the codecs themselves (lower D/A resolution and/or sample rate) so that no data compression per se is required and thus missing samples are not a serious problem?
Date: 20 Jan 2012 03:57:32 -0000 From: "John Levine" <email@example.com> To: firstname.lastname@example.org. Subject: Re: Some unanswered questions from January 2011 Message-ID: <email@example.com> > It was obviously stupid to use TCP for multimedia applications. Depends on the multimedia. For faux-streaming video, which as far as I can tell is much more popular than real streaming video, TCP works great. That's what Youtube uses. You only need real streaming when latency is a problem, which is largely limited to telephony and videoconferences. R's, John
Date: Thu, 19 Jan 2012 16:21:26 -0800 From: firstname.lastname@example.org (Dave Platt) To: email@example.com. Subject: Re: Some unanswered questions from January 2011 Message-ID: <firstname.lastname@example.org> >>  It was obviously stupid to use TCP for multimedia applications. > >I was intrigued by that statement. [Garrett] mentions discarding list >UDP packets, which might be fine in an uncompressed media stream, but >aren't errors/omissions likely to cause disruption to a compressed >media stream (for comparison, consider that data compression was only >commonly implemented in dialup modems on top of error correction)? Or >is the 'compression' implemented in the codecs themselves (lower D/A >resolution and/or sample rate) so that no data compression per se is >required and thus missing samples are not a serious problem? For multimedia, the compression (e.g. MPEG-2 or H.264) is typically performed offline or in specialized media processors. The data is already compressed before it's handed over to the IP stack for transmission and delivery. Attempts to do on-the-fly compression (e.g. like V.42bis in a modem) are usually futile. Yes, there's some disruption in an A/V stream when data in the stream is lost in transmission. With UDP (or any other best-efforts delivery mechanism) this results in a visible or audible "glitch". Delivery protocols which use UDP or a similar packet mechanism, are usually designed with a data format which tries to limit the damage to the portion of the stream actually lost (e.g. a short segment of audio, or a macroblock or a few of them in a video image). The compression and coding algorithms are designed to support this... e.g. each macroblock is largely self-contained, so that loss of data to the previous macroblock doesn't garble the whole remainder of the screen. When the next part of the stream arrives, the decoder "resynchronizes" quickly, and the error does not propagate elsewhere on the screen. If you use TCP, the protocol is trying to guarantee that all the data gets through, correctly... but it can't guarantee when it gets through. If you're lucky, the TCP retransmissions of lost packets will occur rapidly, and you'll see and hear everything correctly. Often, that won't happen. TCP has an "exponential backoff" behavior, and packet retransmissions may end up being delayed for quite a while under some circumstances. When this happens, delivery of the WHOLE STREAM will stop... you won't be able to decode anything beyond the point of the first lost/delayed packet, until the retransmission occurs. This can lead to your A/V decoder "starving" - it runs out of data in its buffers; the audio stops and the screen freezes. This is often much more distracting than a little bit of sparkly macro-block tearing on the screen, or a momentary blip of silence in the audio. Another possibility, if you're using UDP, is to encode the compressed data with a level of redundency and cross-interleaved forward error correction (e.g. Reed-Solomon) before you break it up into UDP packets. This costs you bandwidth, but it means that you can reconstruct the whole set of compressed data, correctly, even if a few packets are lost in transmission. -- Dave Platt <email@example.com> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do not wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads!
Date: Thu, 19 Jan 2012 18:49:39 -0600 From: firstname.lastname@example.org (Gordon Burditt) To: email@example.com. Subject: Re: Ringing Finally Ended, but There's No Button to Message-ID: <WqCdnUFYLvy-J4XSnZ2dnUVZ_gudnZ2d@posted.internetamerica> >> All it may need is one lazy app developer to bypass the bits that control >> to alarm modes and then you have a device that can only be shut off with a >> hammer (or the power button....) >> > The iphone, blackberry and nokia all ignore the off switch to sound an > alarm that you have set. I'd be interested in knowing what Blackberry apps exist that won't obey the "sound profiles" Blackberry provides, which includes both a "Silent" and "Vibrate-only" mode, and allows the flexibility to create a "Vibrate-also" mode, useful in a very noisy machine room where ear plugs are needed to preserve hearing. It covers various alerts for all sorts of things: phone calls, reminders, alarms, social feeds, texts, tweets mentioning you, etc. It's always on the home screen with a little picture of a speaker that indicates the current mode. It's one place to change all the alerts all at once. Apps seem to be able to register their own sounds in a sound profile. The original version of Blackberry OS on my phone (from 2 years ago) wasn't quite so easy about "airplane mode". You had to find the right icon to control this. Now, there's a place on the home page you can click, then there's this nice big button that says "Turn off all connections". It also asks "are you sure" before making an emergency call, which it didn't before. I've used calendar and reminder apps (including 3rd-party ones) and never had any problem with them making noise when the profile is set to "Vibrate-only" (Ok, vibrate-only makes a little noise and isn't appropriate for a theater. For company meetings, it seems to be acceptable if you leave the room to answer or return a call, unless you're the biggest Boss there, in which case you can leave it on !!EXTRA LOUD!!.) or "Silent". I am surprised our theater-going iphone user had such a problem turning off the alarm. While finding where the alarm was set up and removing it might take some time, dismissing an active alarm is usually in-your-face easy. That popup in the center of the screen gives you choices to dismiss it, and you usually can't do much else with the phone until you choose one. I hope anyone who is going to a theater that implements one suggestion here of turning in all the phones before the concert doesn't ask for my contact info. You shouldn't be turning over your phone with Personally Identifiable Information to anyone unless you trust them a lot (that doesn't necessarily include your spouse, parents, or kids). On the other hand, I'd have no problem with a request to put the battery in one pocket and the phone in a different pocket. iPhone users might have trouble with this. You also might lose your phone, if not to a thief, to some well-meaning person who thinks that every color _type_-phone _model number_ is hers without checking. (I am reminded here about the lady at the airport a few decades back who insisted it was her bag, not mine, and went on threatening to call security for 5 minutes even after I pointed out that my baggage claim check number matched, and hers didn't, and the bag (not a tag on it) had my name and address on it. She threatened to call security, while I was walking towards and waving at the nearest guy who looked like security. He said it was my bag, and she left.) I don't quite agree with the moderator's claim that answering your phone anywhere in public is rude. If it is reasonable for me to have a conversation outdoors in a normal voice with someone standing next to me, it seems equally reasonable that talking on the phone in the same voice is OK. (I shouldn't be blocking (pedestrian or vehicle) traffic, walking into moving trains, trying to walk into an open elevator shaft, or holding up a line talking on the phone while at the head of the line. Yes, I've seen people doing all of these.) Why can't I do that on a public sidewalk, in a park, walking down a street, or standing in line overnight to buy the latest new iPhone? No, that's not an excuse to use it in a theater or classroom, while hogging a stall in a crowded restroom, in a business meeting, or while driving. ***** Moderator's Note ***** "our theater-going iphone user" probably tried to ignore the sound, assuming it was going to go away on its own, which is more fuel on the 'RTFM' fire. "Anywhere in public" does not mean in the middle of an open public space, and I'm surprised that you infer that meaning. I was referring to public gatherings, where there is an expectation of discretion from the participants whom are not there to speak or perform. Bill Horne Moderator
Date: Fri, 20 Jan 2012 01:14:33 +0000 (UTC) From: firstname.lastname@example.org (Garrett Wollman) To: email@example.com. Subject: Re: Some unanswered questions from January 2011 Message-ID: <firstname.lastname@example.org> In article <2755e$4f1888cf$adce4530$30287@PRIMUS.CA>, Geoffrey Welsh <email@example.com> wrote: >Garrett Wollman wrote: > >>  It was obviously stupid to use TCP for multimedia applications. > >I was intrigued by that statement. [Garrett] mentions discarding list >UDP packets, which might be fine in an uncompressed media stream, but >aren't errors/omissions likely to cause disruption to a compressed >media stream (for comparison, consider that data compression was only >commonly implemented in dialup modems on top of error correction)? When you packetize multimedia streams, you normally do so on boundaries that align usefully with the codec's idea of what an indivisible unit of data is. (You often want to do this even for "reliable" transfers, because the same mechanism also allows fine-grained seeks, which you usually want for user-interface reasons.) The terminology differs from codec to codec; for telephony-type codecs there's usually a concept of a "frame" which makes a natural boundary -- between 10 and 50 ms is the range I recall. Codecs that couldn't do this were rejected as unsuitable. Generally people were interested in real-time applications like conferencing and telephony, so only low-latency codecs were in the running anyway. -GAWollman -- Garrett A. Wollman | What intellectual phenomenon can be older, or more oft firstname.lastname@example.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993
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.
43 Deerfield Road
Sharon MA 02067-2301
bill at horne dot net
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) 2012 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.