30 Years of the Digest ... founded August 21, 1981
Add this Digest to your personal
or 
The Telecom Digest for January 20, 2012
Volume 31 : Issue 20 : "text" Format
====== 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
owner.
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 <withheld@invalid.telecom-digest.org>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: The Save Our Political Assets act
Message-ID: <b0a3041e-7806-4918-8800-c357b9ee2527@dp8g2000vbb.googlegroups.com>
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" <gwelsh@spamcop.net>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.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" <gwelsh@spamcop.net>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.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" <gwelsh@spamcop.net>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <2755e$4f1888cf$adce4530$30287@PRIMUS.CA>
Garrett Wollman wrote:
> [3] 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" <johnl@iecc.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <20120120035732.43059.qmail@joyce.lan>
>[3] 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: dplatt@radagast.org (Dave Platt)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <6lomu8-thv.ln1@radagast.org>
>> [3] 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 <dplatt@radagast.org> 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: gordonb.f4zj1@burditt.org (Gordon Burditt)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
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: wollman@bimajority.org (Garrett Wollman)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Some unanswered questions from January 2011
Message-ID: <jfaf5p$26ne$1@grapevine.csail.mit.edu>
In article <2755e$4f1888cf$adce4530$30287@PRIMUS.CA>,
Geoffrey Welsh <gwelsh@spamcop.net> wrote:
>Garrett Wollman wrote:
>
>> [3] 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
wollman@bimajority.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.
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.
End of The Telecom Digest (8 messages)
Return to Archives ** Older Issues