<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Andrew,<br>
<br>
Andrew Kohlsmith wrote:<br>
<blockquote type="cite" cite="mid200403191108.44043@-mixdown.ca">
<blockquote type="cite">
<pre wrap="">My personal preference is OpenBSD pf because I think it allows for a lot
more flexibility. I have all my VOIP traffic scheduled in the realtime
queue, priority 1.
</pre>
</blockquote>
<pre wrap=""><!---->
iproute2 gives this power to Linux as well -- I am going to try Mike's
jitter fix, but I am using tc to give VOIP traffic top #1 priority as well. </pre>
</blockquote>
IPRoute2 and TC interacts only on outgoing packets, not incoming. So,
you must be carefull about traffic assertations.<br>
<br>
1) NAT can produce overhead and packet fragmentation.<br>
<br>
2) Wireless can produce "fallbacks" and retransmissions.<br>
<br>
3) iproute2 and tc estimators are statistics and they depend on some
hardware specifications. A good example is "near wire-speed transfer".
Please, refer to HTB tutorial (<a class="moz-txt-link-freetext" href="http://luxik.cdi.cz/~devik/qos/htb/">http://luxik.cdi.cz/~devik/qos/htb/</a>)
and LARTC (lartc.org)<br>
<br>
Daniel<br>
<br>
<blockquote type="cite" cite="mid200403191108.44043@-mixdown.ca">
<pre wrap="">
I believe that the true fix for any kind of jitter is making ABSOLUTELY SURE
that it is the endpoints doing the buffering and NOT the transmission
equipment. If the DSL modem or wireless equipment buffers are full it
doesn't matter how much prioritization you do. It is absolutely essential
that any serious VOIP system have control over both endpoints' routers to
ensure that the link itself does not become saturated.</pre>
</blockquote>
<blockquote type="cite" cite="mid200403191108.44043@-mixdown.ca">
<pre wrap="">
A poor-man's solution is to limit the incoming bandwidth to something just
slightly less than what the link will support. This only works with TCP
traffic, though, since neither UDP nor ICMP have any provision to back off
if messages aren't getting through.
Regards,
Andrew
_______________________________________________
Asterisk-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Asterisk-Dev@lists.digium.com">Asterisk-Dev@lists.digium.com</a>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
</blockquote>
</body>
</html>