FCC now planning "all-IP" phone transition [Telecom]

So, would it be accurate to say that a packet switched network could have high quality voice transmissions (as good or better than existing landlines) if they were properly engineered to do so?

On Sat, 09 Jan 2010 18:27:15 -0500, Eric Tappert wrote: ...........

Yes and no, there is usually a configurable option on VoIP end devices to keep sending packets on silence or not to save on bandwidth (Voice Activity Detection):

-- Regards, David.

David Clayton Melbourne, Victoria, Australia. Knowledge is a measure of how many answers you have, intelligence is a measure of how many questions you have.

How is the circuit gain well over 100%? If it's a two way conversation with each person talking 50% of the time, it seems that you'd get a gain of 100% by dropping in other circuits during the idle times in each direction. There are, of course, other pauses, and people don't start talking right when the other person talks (though my wife says I start before she's finished, but that's another story). So, the circuit gain COULD go a bit above 100%. I was assuming they would leave some reserve circuits to handle the times when more than 100% of the people were talking in one direction, but your mention of dropping the encoding level in digital TASI makes sense. They could, I suppose, drop bandwidth per channel on analog TASI, but that seems complex. So, for analog TASI, did they leave some excess circuits to handle the peaks?

This sort of multiplexing is interesting. The data stream is bursty (even in analog, since there are pauses with no speech). Without multiplexing, you're stuck with allocating a full circuit to the data. With multiplexing, though, the bursts of one stream can fill in the valleys of another stream, decreasing the required bandwidth. With real time streaming, though, there are times where the peaks coincide and you run out of bandwidth. Moving from real time to near real time by adding buffers, you can shift the peaks such that they do not coincide, then restore the timing at the receive end. I think this works very well for stuff like satellite television where a bunch of channels can be put in one datastream. A scene change in the video results in a spike in the data rate since the entire screen has to be redrawn, instead of just the changes. But, this spike can be time aligned with a static scene where no data is to be sent. With a large enough buffer, you can get real high usage of the available bandwidth. Any excess can, of course, be used for non - realtime data, such as program guide info, subscriber authorizations, etc. With voice, however, latency is really a problem since the speakers become confused. I often get confused on a digital cellphone and start talking over the person I'm talking to (especially my wife, but, again, that's another story).

Moving away from TASI a bit, but still staying with statistical multiplexing, I've been giving more thought to network neutrality and traffic shaping. If indeed ISPs are suffering from network congestion, prioritizing of traffic may make sense. Email probably does not have to be delivered as quickly as interactive video. I believe IP has bits allocated to packet priority. ISPs could charge different rates based on the packet priority. They could also go to time of use metering to try to even out the load. Economics could provide a method of allocating limited resources.

Anyway, thanks for the TASI discussion. It's been a long time since I saw that system at the AT&T underground building in San Luis Obispo. They had a pamphlet entitled "San Luis Obispo, Communications Center of the World" showing the various Pacific undersea cables.

Harold

Though note that digital voice detectors are capable of storing a FIFO's worth of samples from *before* the "on" decision is made and can include those in the outgoing stream ... at the cost of delaying the *entire* "on" period by that much [that is, by the attack time of the detector]. While increasing end-to-end delay is never desirable, increasing it by just enough to restore the clipped portion is probably worth it.

-Rob

----- Rob Warnock

Why not just speed up the first second or two of the "on" period until it gets back to real time? That should be well within the capability of modern DSPs. Don't raise the pitch, just throw away every Nth sample, analogous to the way they used to use rotating tape heads.

R's, John

Harold,

"Better than 100% gain" is all in the statistics.... Actually very few people talk 50% of the time and on average it is less than 50%. If I recall correctly it is about 40%. Of course there are cases when both parties speak at the same time (little useful information, perhaps, but they get bandwidth anyway...) and there are other cases with virtually no active speech (two lovestruck teenagers, for example. Just an occasional sigh...). Modems demand 100% all the time, so they screwed things up by requiring a dedicated channel.

If I recall correctly, digital TASI used 5 T-1 lines running ADPCM for a total of 240 channels per set and they connected to 480 trunks. That allowed for enough margin that the bit robbing was seldem used, but most of time, even with 480 active trunks, there were plenty of spare channels. Not pushing things above 100% was really a quality of service issue, as the gain was already significant and the incremental improvement was small relative to the quality of the circuits.

Analog TASI was similarly configured, but I think a set was only 5, 16 channel groups (I could be wrong, it was a long time ago and my experience was with the digital stuff...). In any event, the larger the set the better the statistics work. I really don't know how many of these circuits are still in use as undersea fiber is really cheap these days...

Before anyone cares to argue that a group was only 12 channels, that was not true for undersea analog cables. To increase capacity they used 3 kHz channels and SSB modulation to fill a standard group (60-108 MHz) with 16 circuits instead of 12, 4 kHz channels.

Hope this helps.

ET

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

One of my favorite stories, though quite possibly fictional, is about an organization that tested their backup power systems regularly but failed to notice that the fuel pump was actually connected to mains power so, while every test was successful, during a real power outage the generator spluttered and died...

Which reminds me of my favorite story, which, similarly, may or may not be true. I've never been able to verify it one way or another, and the folk involved have pretty much all met up with Father Time.

Back in 1965 we had the Big Northeast Blackout (thank you, Canada) [a], which included NYC.

While emergency power was pretty rare back then, hospitals generally had something on line.

Sure enough, Bellevue Hospital in Manhattan, NYC, had some pretty large (by 1965 standards) backup generators, and they soon came up and gave the hospital functional power.

Except that... well...

.. as you can well imagine, the generators back then were physically very big, and heavy, and were sitting on the concrete pads in the basement. Make that sub, sub, basement.

Bellevue (and Manhattan in general) isn't very high above sea level, and the generators were pretty far down.

Turned out that the sump pumps weren't hooked up to the backup power...

(About fifteen years later I did, in fact, get to see the generators in questions. And sure enough they were pretty deep, and there was a small pool of water around them from the constant drainage.).

The internet publication "Risks Digest" is filled with examples of this sort. It's well worth reviewing for anyone considering how to design things to keep working.... [a] the blackout started at the Sir Adam Beck substation in Canada, near Niagara Falls, and cascaded from there.

Or this place where there was one large UPS powering a number of important servers, but only one server was directly connected to the UPS for control purposes and all the other servers got their shutdown instructions via LAN software from this control server.

Various tests of unplugging the UPS power brought all the servers down as anticipated, and all involved patted each other on the back because of the completion of (yet) another successful project......... until....

The main power did one day go off and only the directly connected server shut down properly - because the LAN equipment that all the other servers relied on wasn't powered by a UPS!

This story has been modified to protect the incomp... I mean innocent.

-- Regards, David.

David Clayton Melbourne, Victoria, Australia. Knowledge is a measure of how many answers you have, intelligence is a measure of how many questions you have.

LOL! When we did ours we attached the power whips coming out of the Symmetra to the server racks and shelves, even extended a whip out to the telecome gear.

An indoor generator will have a "day tank" -- one with enough fuel for a few hours or more. The rest of the fuel will be outside with a transfer pump.

At an installation I inspected, that pump was not an emergency load, and so it would have run for no longer than that.

Neither were certain other vital systems; something never uncovered in

After staging a full "pull the utility feed and see what happens.." test; these items were soon resolved.