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/