On Tue, 30 Nov 2010, Steve Jones wrote:
Just the contrary - Most QoS schemes will drop TCP first, specifically because it is known that with TCP, the packet will be resent, so no application will be hurt. UDP is not dropped first because it is known that there will likely be more impact. I am not aware of any way to run IAX over TCP, and I agree it would be a bad idea. The proper thing to do is to implement PROPER QoS on BOTH SIDES of the link, which I hope is point to point. If it goes over the Internet, your QoS is lost as soon as it hits a router you dont control (or pay for QoS services on) I think in IAX, the jitter buffer size can be adjusted, but I dont know the detail on this.. A jitter buffer can be looked upon as like a funnel - as packets arrive, they are dumped in the funnel, which is then pouring your audio out the bottom in a smooth stream, no matter how much delay there is in the filling of the funnel. When the funnel runs out of packets (ie: delay has caused you to run out of data) then you get a break in your audio stream. Increasing the jitter buffer (bigger funnel) can fix this, but at a certain point, the audio will be SO DELAYED (because the packets are waiting in the buffer) that the users will notice and get confused.
Just want to point out that a jitterbuffer will do NO GOOD if packet loss is occurring. Proper QoS on both ends is ideal of course, but I have seen some pretty clever ideas employed on the CPE side of link to effectively provide QoS in both directions, when you have no control over your ISPs routers. For example - you can effectively control the inbound flow of a TCP based application by delaying the ACKs sent back to the content provider. Doesn't help you with UDP streams though, unfortunately.
j
-Steve ---------original message ------ From: "Mike" <[email protected]> To: "'Asterisk Users Mailing List - Non-Commercial Discussion'" <[email protected]> Date: Tue, 30 Nov 2010 12:34:08 -0500 Subject: Re: [asterisk-users] TCP port, VPN and resolving the cutting voice problem > I know understand the latency due to the resending .. But if the link was have a good speed internet, then resending will make a big latency? I think the point is that with TCP, congestion will create a vicious circle of more congestion, while with UDP congestion is bad in itself, but doesn't result in more congestion created by the original congestion. That being said, isn't UDP sometimes looked at as being lower priority than TCP by many routers out there and dropped first when congestion does occur? That makes it a good reason to use TCP in some cases. Mike
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
