Hi,
I've been trying to figure out the best way to deal with having a ridiculously low bandwidth and wanting to make phone calls. The advice I could find in the knowledge base suggest using traffic shaping. That turned out not to work, probably because it is impossible to control the incoming traffic. With a downstream of only 455kbit/s, all the available bandwidth is always more than occupied unless nothing else goes over the line, or I limit the bandwidth usage of the applications receiving traffic from the internet --- which gets annoying.
Finally I found some time to experiment with this and seem to have found a solution: limit the incoming traffic with a fixed limiter instead of trying to shape the traffic depending on demand. The configuration for this currently looks like this:
ubnt@ubnt# show traffic-policy fair-queue fair { hash-interval 5 queue-limit 20 } limiter lim1 { class 1 { bandwidth 128kbit match VOIP-RTP { ip { dscp 46 } } match VOIP-SIP { ip { dscp 24 } } } default { bandwidth 327kbit } } ubnt@ubnt# show interfaces ethernet eth0 { address 192.168.3.1/24 description Local traffic-policy { out fair } vif 100 { address 192.168.1.1/24 description dmzlike } } ethernet eth1 { description "Internet (PPPoE)" pppoe 0 { firewall { in { name WAN_IN } local { name WAN_LOCAL } } password foo user-id bar } traffic-policy { in lim1 out fair } }
That constantly takes 128kbit/s off the bandwidth and keeps it available for VOIP. It's not ideal because receiving data takes a bit longer due to the reduced bandwidth, but phone calls still work when the line is otherwise fully occupied.
I thought I'd share this in case there are others having problems with low bandwidth. If there is a better solution, I'd like sure to hear it Image may be NSFW.
Clik here to view.
PS: Perhaps I should do something else than a fair-queue with the upstream traffic. I'm not sure what, though.
PPS: Using a smart-queue configured via the GUI resulted in phone calls being aborted after about 8--15 minutes. Is that a bug or to be expected?