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.


On 07/30/2010 11:37 AM, Jonas Kellens wrote:
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.

I read that there is not really a way of shaping incoming traffic on Linux (ingress).

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.


Kind regards,

Jonas.


On 07/30/2010 03:36 PM, William Kenworthy wrote:
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

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

Reply via email to