VoIP - Static and Dropped Calls

I’m running into a problem where the internal traffic (high volume, large data files) is causing issues with VoIP traffic (static, dropped calls, the whole shabang)

My setup is like this : Total of 3M pipe. common local-bridge, common internal DHCP network (192.168.1.0/24). I have one interface on the MT dedicated to a “data switch” and one dedicated to a “phone switch”
I implemented a simple queue to prioritize traffic to our hosted VoIP provider, but it doesn’t seem to be fixing the static on the calls and dropped calls (actually seems to be causing one-way audio issues). I have even implemented a bandwidth limitation on the data port to 2M, and a full 1M for the VoIP traffic (but again, this doesn’t seem to have completely fixed the issue)

I’m at a loss as to what to try next.

I have very good results with a queue tree where one queue is applied directly on the outgoing interface
with a limit-at and max-limit slightly below the actual link speed (e.g. 2900k in your case), and below that
there are several queues with limit-at about 1/4 of that value and max-limit the same as above.
These have a priority, and the voice traffic gets a higher priority than the data.
It works very well. Of course you have to do this at the output side of each router, so when your VoIP
provider is on internet it has to be done at the internet provider side too.

My further attempts include setting up Mangle to tag connects and packets going to or from a specific public IP address (outside the network) as VOIP, and everything else as OTHER

I then created a queue trees : PRI_UP, PRI_DOWN, BE_UP, and BE_DOWN. I set the max-limit to 2700K on all 4 parents, then added leaves stating anything marked as VOIP has priority 1, anything else has priority 4.

I’m still running into one-way audio and static on the line.

My fear is that large internal file transfers are stepping on traffic before it reaches the router. Would changing the Parent on the parent queue containers from ether1 (WAN port) to global help?

You create a queue tree by first creating an element with the internet interface as parent, then
below that some elements with that first element as parent, then you assign the traffic to the elements
according to priority.
It is only useful to do this for OUTgoing traffic on an interface. Shaping INcoming traffic only risks
dropping important traffic, it is not going to change the relative priority.
So you need to do this on both ends of each link for it to be completely effective.
When you are on a regular internet connection and the other side (the ISP) does not have shaping
like this, there is little you can do about downloading. Fortunately the download speed is much more
than the upload speed, so it has less effect on the problem. When your problem is in the download
direction (you hear the static but the other side does not), there is little you can do apart from asking
your ISP to improve the configuration of their routers, something they usually don’t do because they
also offer a “business grade” product on which they offer that service.

Ok. Here’s another piece to the puzzle:

The site has a a bonded T1 connection: 3M up, 3M down. They are stating they still get heavy static on calls. Below is my current Queue Tree. Maybe I didn’t set it up correctly?

0 name=“PRI_UP” parent=ether1-WAN packet-mark=“” limit-at=0 queue=default priority=1 max-limit=2700k burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
1 ;;; Priority Traffic
name=“PRI_DOWN” parent=ether1-WAN packet-mark=“” limit-at=0 queue=default priority=1 max-limit=2700k burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
2 name=“BE_UP” parent=ether1-WAN packet-mark=“” limit-at=0 queue=default priority=4 max-limit=2700k burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
3 ;;; Best Effort Traffic
name=“BE_DOWN” parent=ether1-WAN packet-mark=“” limit-at=0 queue=default priority=4 max-limit=2700k burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
4 name=“voip_U” parent=PRI_UP packet-mark=VOIP limit-at=0 queue=default-small priority=1 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
5 name=“voip_D” parent=PRI_DOWN packet-mark=VOIP limit-at=0 queue=default-small priority=1 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
6 name=“be_U” parent=BE_UP packet-mark=OTHER limit-at=0 queue=default priority=4 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1
7 name=“be_D” parent=BE_DOWN packet-mark=OTHER limit-at=0 queue=default priority=4 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1

What does it look like in the GUI? Do you see the queues matching traffic and limiting it?

Yes. I see dropped packets in my Best Effort queue. Should I limit this queue to 2500K instead of 2700K ? I’m seriously at a loss for what I can do to fix this VoIP issue.

For you VoIP packets, setup limit_at, is the CIR.. minimum guarantee for this.
For example, 128k, it will be always HAS it… at least

I’ll give this a try and see what the results are on Monday. Set a limit-at to 512K
That should in theory give them enough minimum bandwidth for their VoIP calls

Yes, please do it. Remember, the sum of limit-at of everything never could be greater than your guarantee bandwidth.

Because the system will give ALWAYS the “limit-at” to each queue.

And also, setup some importart queue/mangles to PCQ queue.

Check this

http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ

http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ_Examples