Its quite the opposite actually. It's much better to drop VoIP packets on VoIP codec streams (aka RTP streams) than it is to queue them. From my experience you can loose about 30% of the packets on a G.711 RTP stream within minimal impact on the voice itself. Queuing them on the other hand causes the jitter buffers to start extending themselves to compensate in the variations in latency caused by the buffer. This leads to a lag between when you speak and you hear the other person responding on the other end responding to you. I find rate limiting works best for UDP and traffic shaping works best for TCP. ps. UDP streaming applications don't re-transmit packets. If your doing something real time and you loose the packet, you loose the packet. This can lead to the video becoming jumpy, or the audio breaking up. -----Original Message----- From: Erin Salmon - Unleash Computers Ltd [mailto:erin(a)unleash.co.nz] Sent: Friday, 18 March 2005 2:40 p.m. To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] telecom planning to break VoIP over its network? In regards to Craig Spiers' comments, I doubt Telecom would see any amount of processing power as justification not to render VoIP useless on their networks. 20,000 Skype users must be hurting them. I think you can be 99.9% confident that IDGs statements about UBS are correct. Try using a VoIP application on a UBS line, especially during peak times, and you'll see what I mean. In order to cap the speed to 256kbps Telecom does just drop packets. I understand this is a limitation of the current hardware at the exchanges, and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source. NZ needs some competition in the Telco market.