<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
There's no real way of shaping or applying QoS on inbound interfaces
on any device. You can affect how that traffic behaves once it's
entered your device, but not how it's queued on its way to that
device. Think of lit like trying to stanch the flow of water at the
end of a hose rather than simply turning the pressure down at the
spigot. To properly queue, it has to be done on egress, so you'd be
better off looking at applying QoS to whatever moves traffic to your
astersk box if "input" traffic on the asterisk box is the issue.
You can, of course, effectively setup queuing outbound return
traffic *from* the asterisk box.<br>
<br>
<br>
On 07/30/2010 11:37 AM, Jonas Kellens wrote:
<blockquote cite="mid:4C530DDC.7070107@telenet.be" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
<font face="Helvetica, Arial, sans-serif">My problem is that my
Asterisk server is sometimes also FTP-server for uploading of
MoH-files. I don't want this FTP-traffic to interfere with
ongoing
VoIP-calls. Therefore I would like to give priority to the
RTP-traffic.<br>
<br>
I read that there is not really a way of shaping incoming
traffic on
Linux (ingress).<br>
<br>
Anyone on this list know how to deal with other packets coming
in on
the same interface ?! I have a gigabit link on a gigabit
network... but
don't know if this is enough.<br>
<br>
<br>
Kind regards,<br>
<br>
Jonas.<br>
<br>
</font><br>
On 07/30/2010 03:36 PM, William Kenworthy wrote:
<blockquote cite="mid:1280496966.16874.105.camel@rattus"
type="cite">
<pre wrap="">HTB is a bad choice for VoIP. When it "borrows" bandwidth, according to
the docs it doesnt release it back until its finished so if its using
all the bandwidth for a download before the VoIP call starts, VoIP gets
starved even if you reserve an excess of bandwidth as it still queues.
When I tried it sort of worked but didnt have the effect I expected on a
busy link, probably for this reason.
HTB tries to be fair about sending packets but with VoIP being fair
sucks :) A better way is to use a "prio" filter at the root, the
priority 1 branch having a plain fifo on it - send VoIP and acks only
this way.
The priority 2 branch has a HTB hierarchy with sfq leaves for the rest
of the traffic.
This seems to work much better, but I have not tested well yet. I am
also using a police filter for incoming (on ADSL) and have not noticed
any problems - but it is only lightly limiting (to try and keep the
queues at the ISP end short.)
Lastly, test to make sure the packets are flowing where you expect them
to - I had to correct a few miss-understandings I had on how it all
worked before everything went where I wanted it to :)
TC and TCNG do seem dead, but I think thats partly because its
relatively mature and doesnt need much work.
BillK</pre>
</blockquote>
<br>
</blockquote>
</body>
</html>