[asterisk-dev] [Fwd: [svn-commits] oej: branch oej/iaxtrunkfix-1.2 r44779

[Rich Adamson]

Author: oej
Date: Tue Oct 10 04:43:12 2006
New Revision: 44779

URL: http://svn.digium.com/view/asterisk?rev=44779&view=rev
Log:
Add patch for setting MTU on trunks.

With a large amount of traffic on IAX2 trunks, there is bad voice 
quality due to the fact that the
IAX2 trunking scheme depends on the Linux system to handle fragmentation 
of UDP packets. This is
not very efficient. This patch adds the ability to set an MTU size for 
*ALL* iAX2 trunks in
Asterisk 1.2. In the patch for svn trunk, we will add new features, like 
setting MTU per trunk.
In the case of Asterisk 1.2, we wanted a small clean patch to be able to 
get voice quality back
without changing a lot of source code.

--------------------------------------------------

For those that get very serious about QoS in WAN and LAN links, 
fragmenting packets to various sizes depending on actual bandwidth 
available is very very important.

Couple of examples:
1. On T1/E1/ethernet circuits (and faster), fragmentation is of little 
concern as a 1500 byte packet consumes approx .9 milliseconds to 
transmit (across a T1). That suggests there are many opportunities to 
squeeze in a 20 millisecond rtp packet.

2. On a sdsl circuit with 512k bandwidth in both directions, a 1500 byte 
packet will consume substantially more transmission time, impacting the 
ability to squeeze a 20 millisecond rtp packet into the serial stream.

The issue that occurs in #2 is that once a large (1500 byte) packet 
begins to flow across a slow speed link, there is no way to stop that 
flow to insert a 20 milliscond rtp packet, thus creating jitter at best. 
QoS settings (in any form of box) will not impact this problem.

Cisco has created methods in its latter IOS versions that forcibly 
fragments large packets so that QoS has a reasonable chance of moving 
rtp packets and minimizing jitter.

The actual MTU size to be used should be a parameter of each 
transmission path, and again, the MTU size "is" directly related to 
available bandwidth.

Rich