[asterisk-users] TCP port, VPN and resolving the cutting voice problem

[Dave Platt]

> 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.