> 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? > > Maybe this latency better than having a cutting voice?
Fundamentally, TCP's congestion-avoidance and loss-recovery logic simply won't work well with voice, unless you're willing to accept a really horrendous latency (hundreds of milliseconds) and then perhaps not even then. TCP is designed to ensure reliable data delivery and reasonable network efficiency (i.e. avoiding congestion and avoiding an excessive number of retransmissions) and is simply not well suited for isochronous (or close-to-isochronous) data streams such as VoIP. > What if we reduce the packet size and make it TCP, so resending might cause > acceptable delay? > > But again, what about running IAX in TCP port, this is possible? Sure, it is *possible*. I don't think anyone has implemented it, because everyone who might is probably pretty well aware that it would not work well. > Any other solution to resolve the cutting in the voice while others doing > download and browsing? I'd recommend the following general approach (not my own ideas, just ones I've adopted from other peoples' recommendations): - Deliberately "throttle" both inbound and outbound TCP connections, so that they do not consume all of your link bandwidth. Set aside some amount of the link bandwidth for VoIP traffic (SIP or IAX2) traveling over UDP. For outbound traffic, what you need is a rate-limiting traffic shaper which supports multiple queues. Linux can do this with its advanced traffic shaping modules. For inbound traffic, what you need to do is prevent the sending TCP stack (at the far end) from being able to queue up and transmit an excessively large amount of traffic. Since you have no *direct* control over the remote systems, you have to do it indirectly... and the way you do it is by "input policing". This simply means that when incoming TCP packets start consuming more than a specific percentage of your inbound bandwidth, you start dropping them... artificially creating a "lost packet" error, which then causes the sending system to reduce its transmit window and enter a congestion-avoidance process. This also can be done using the Linux traffic-shaping modules. - Prioritize the packets you send, with VoIP packets being transmitted before TCP packets. This can be done using a combination of traffic-shaping modules (to set up and prioritize the queues and set their transmit rates) and iptables (which can be used to mark VoIP packets as needing expedited delivery). Take a look at http://lartc.org/howto/ - it's a complex subject but a well-designed traffic shaping configuration can have really excellent benefits. -- _____________________________________________________________________ -- 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