
I think you just tossed a red herring into the discussion. :-)

I would suggest that a semi-intelligent playback bufferring scheme
in the VoIP application, plus a 'semi-lossless' link, would be just
fine.  ;-)

Doesn't anyone really remember the whole smart-v.-stupid network
analogy? Not meaning to start a flame war here, but trying to stick
all of the intelligence back into the network is not exactly a win-win
proposal.


- ferg


-- Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Fri, 16 Dec 2005, Christopher L. Morrow wrote:

When you're running voip over a T1/E1, you really want to LLQ the VOIP 
packets because VOIP doesn't like delay (not so much a problem) nor jitter 
(big problem), nor packetloss (not so much a problem if it's less than a 
0.1 percent or so).

So combining voip and data traffic on a link that sometimes (more often 
now when windows machine have a decent TCP window) go full, even just in a 
fraction of a second, means you either go QoS or do what Skype does, crank 
up the jitter buffer when there is high-jitter, which means latency for 
the call goes up.

[snip]

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg@netzero.net or fergdawg@sbcglobal.net
 ferg's tech blog: http://fergdawg.blogspot.com/


