I’m a beginner with Mikrotik, and I try to do VoIP traffic shaping, so I read this document : https://mum.mikrotik.com/presentations/US16/presentation_3004_1462512668.pdf, and I tried to apply that to my configuration.
It kinda works, when I make a call, I have about 80kbps flowing through the max priority upload queue tree, and the voice quality is ok in the outgoing direction.
But, in the max priority download queue tree, I only see 1kbps traffic, and the quality is bad in the incoming direction.
I can’t get it to work in both directions, it’s like if the incoming packets are not marked.
Do anybody here know how to fix that ?
Thanks,
Joris
PS : excuse my poor english, I’m a native french speaker
There is not much that you can do for the incoming side. That is the task for the other side of the line, where it is the outgoing side. The queues have to be at the outgoing side.
That is fine when you are at both sides, but unfortunately for many people the other side is some Internet provider, and they have no power to make them implement VoIP QoS.
@pcunite : I carefully read the post, and it seems that this is basically what I’ve done on my router, but I will check it
@pe1chl : I understand that I can’t control what is going on on the isp side, but I still should see an activity when monitoring my voip downstream queue tree. When I make a call, there is about 80kbps going through my voip upstream queue tree, which is coherent with a G711a voip call, but there is only 1kbps going through my voip downstream queue tree, but since I still hear the other side, the incoming packets are going through my router, so I think they’re just processed by the common downstream queue tree. So, I think that, for some reason, the packets aren’t marked in my mangle rule, and that’s what I don’t understand, since I tried every way to mark them.
At first, I used the DSCP code 46 to mark outgoing connections, then I marked packets based on connection-mark, but only outgoing packets were marked. And that, I don’t understand, since the incoming packets are belonging to the same connection as outgoing ones, right ?
After that, I thought that it was because incoming packets don’t have DSCP code 46, so I tried to mark connections by destination address or source address, and by udp port, and still nothing…
You cannot have a downstream queue tree!
Likely you have been confused by the upstream/downstream settings for matching of IP addresses.
So you have created another upstream queue that has an incorrect matching that seldomly matches.
A queue is just the same as a queue before a door where people need to pass through.
There is a queue in front of the door of people that need to wait before they can get through, and you can make multiple queues for “important people” that get through first, but it makes no sense to make another queue for people that already entered through the door and assign different priorities to them. The waiting already has happened on the other side.
To help those who maybe reading the above comment for the first time. When we are trying to QoS, it is true that you can not control what the ISP is going to send you. However, you can make requests, ask favors, to an incoming stream of TCP traffic. When you do, it will slow down its incoming rate. This will improve the overall bandwidth contention and is worth doing.
“..you can make requests, ask favors, to an incoming stream of TCP traffic..” → we are not being nice about it , we just drop some packets from that stream and the tcp will resend and slow down…
I have a “download” queue attached to my ethernet bridge (so my LAN), and a “voip_download” queue attached to the “download” queue.
I basically copied what is done in the “QoS best practices” found on the Mikrotik website.
That should work. It’s a bit after the fact, as it already passed the isp pipe, but by controlling the internal “gate” one can also shape the overall throughput.
So you just need to make sure your classification is working.
What I do:
connection-mark all VOIP related connection (which are not already marked). I do it in Mangle:forward.
packet-mark all packets with VOIP connection-mark (which are not already marked). I do it in Mangle:PostRouting.
Well, it’s not, it seems that the mangle rule which mark the connection only see outgoing packets (I only have 80kbps going through it, it should be 160kbps). I think that I must miss something about how RouterOS handle this.
So I tried it, and it didn’t change anything…
There is also those 1kbps which are going through my queue, I think that’s SIP packets (everything on port 5060), so I don’t understand why RTP packets are not.
I assume your pppoe’s are asymmetric, with download speed >> upload speed? if so max on download doesn’t reflect this.
define priority (>2) on maison-* queues
(unrelated to this thread: that’s a risk “add action=accept chain=input dst-port=80 in-interface-list=WAN protocol=tcp”)
with “action=fasttrack-connection” !!! all mangling goes out the window. FastTrack bypasses mangling and you’ll need to adjust your fasttrack rule to exclude VOIP & MYTI traffic. Adjustment example
You have two of these, so bridge on download could receive for download as much as 3200k. That would be it’s max for QoS.
Now if one link goes down, max on brdige will still be 3200k, but the remaining link would already be saturated at 1600. In such situation, QoS will not function properly. Not a lot one can do about that, I guess, just keep in mind.
Thanks for showing me my mistake.
I understand the problem in case of one link down, maybe I can resolve that particular issue with a few lines of script somewhere…
But I can’t find a simple way to execute script on ppp events…
, we just drop some packets from that stream and the tcp will resend and slow down…