I'm currently experimenting with optimizing VoWifi since there isn't a VoWifi handler in Mikrotik. Since UDP ports 4500 and 500 are used, I decided to try out the following idea. It feels like it works better, but not always. Has anyone else looked into this yet?
I would set qos-classifier=dscp-high-3-bits instead. And drop the priority mangle rules. "priority" is a RouterOS internal classification on the current RouterOS instance only. dscp on the other hand can be set by client applications (e.g. ssh clients do set dscp) and is "passed on" (until packets exit your gateway, as ISPs strip dscp).
And then of course: regardless which classifier you choose, it only applies to the wifi-qcom part. If the WAN is your bottleneck, then you also need queuing like CAKE in case you went the dscp path. With priority you need to set up some crazy queue tree for each priority and use packet marks, this is when things get complex fast.
PS: mangle needs fasttrack disabled. So either disabled globally or place an accept rule before the fasttrack rule. something like "action=accept chain=forward dscp=!0"
Port 500 usually does not need special treatment, it is only used for initial key exchange. All the time sensitive voice traffic goes to port 4500.
Most Smartphomes attach real-time priority to VoWiFi traffic which should be handled correctly by WMM for the WiFi part
Usually the bottleneck is the WAN uplink, not the WiFi or internal network, so changing DSCP / WiFi priorities does not help much
Suggested 1st attempt is to attach a CAKE queue to the WAN interface and nothing else yet. CAKE usually does a good job with prioritizing (voice) streams without further configuration.
Some ISPs throttle VoWiFi traffic on their network because they don't like mobile providers to use their infrastructure to safe on radio towers.
Not having inspected myself but I would also think so. And I assume they also set dscp accordingly. Now I am curious. Need to capture a vowifi call and verify.
Probably no help whatsoever, but wifi calling has always worked here on several routers and router AP combinations and i have never needed a VoWifi handler nor had to adjust settings for it to work quite adequately. As for optimization, what is there to optimize? I would like to know what I am missing.
VoWifi generally works, but the quality of my voice is often poor. I can hear the other person, but they hear me muffled, as if I were in the background. If I turn off Wi-Fi and call again, the other person can hear me normally.
This guy found out by capturing the frames that his phone sends the encapsulated vowifi data with best effort. while the ingress frames from his provider were properly dscp marked.
So it probably depends on your phone. Or carrier.
But generally: I do apply connection marks in prerouting chain and then in forward chain mangle based on the connection marks.
When you go with the qos-classifier dscp, then you don't have to "translate" between wmm/priority/dscp. you have dscp the whole path. cake's diffserv can work with dscp.
Whrn the client device does not set wmm or dscp on the frames, this you can't fix with your mangle rules. the path from client->AP remains "best effort". But you can change and have control over the priority/dscp on the path AP->WAN and return path WAN->AP->client.
Usually the bufferbloat happens at WAN egress and not on wireless. Unless your wireless is used for heavy traffic, many concurrent clients which would consume a lot of airtime.
Thanks for the article... if I understand it correctly:
Inbound (Provider -> Access Point -> Smartphone):
The provider properly tags incoming packets with DSCP 46 (EF / Expedited Forwarding).
The Access Point detects this and transmits the Wi-Fi frames to the smartphone using WMM Voice (Priority 6 / AC_VO).
Result: You can hear the other party crystal clear most of the time.
Outbound (Smartphone -> Access Point -> Router -> Provider):
The Android smartphone fails at QoS tagging: it transmits its own voice packets untagged as DSCP 0 (Best Effort / WMM Priority 0).
Result: Both the local Access Point and the router treat your own voice traffic like ordinary web surfing or download traffic. As soon as bandwidth is consumed elsewhere on the local network, the outbound voice packets get queued and delayed -> the voice sounds choppy or drops out for the other party.
So maybe my/your approach isn't wrong after all:
The mangle rule addresses this exact gap: Because the smartphone sends outbound packets with DSCP 0, the MikroTik intercepts the UDP 4500 packets and rewrites them to DSCP 46.
Cake SQM on WAN: Cake reads the corrected DSCP 46 tag and immediately pushes the voice packets ahead of all other uploads at the upstream bottleneck.
Wi-Fi QoS: Setting qos-classifier=dscp-high-3-bits on the MikroTik AP ensures that the wireless medium handles the prioritized frames correctly as well.
Yes, AI recap reads correct. Except your RouterOS mangle rules can't fill the gap client->ap. Assumption: your phone does not apply dscp/wmm priority already. Morenlikely your WAN is the "bottleneck" and not wifi. But that's were cake queue kicks in.
Bandwidth is not that important. varying or high latency/jitter is what cause stuttering, bad sound quality, etc. So you need to find out where inside your network the issue is located. Usually it is not the wired path. And I assume your 100M upload is mostly unused. So the suspect could be the wifi path. btw, which Mikrotik wifi ap is it?
Not wifi calling, but VoIP: I have a run of old telephone wire pressed into service as an ethernet cable, which has run for about 3 years serving a VoIP connection. It syncs at 10 Mb/s and runs fine. Quality used too be poor at times but when we went from Wireless Internet to Fibre on the WAN, it improved dramatically. If 10Mb/s is good enough for VoIP, it will be OK for wifi calling. I cannot imagine cell phone companies doing anything other than minimizing the bandwidth requirements.
[Coincidentally, that old telephone wire is coming out of service today]
I don't think so. You will find that they send the voice traffic with the correct priority. Don't think that seeing a couple of packets with priotity 0 means it is wrong, there are different kinds of traffic over the same port and not all of it needs priority, it is not useful (maybe even counterproductive) to change it all to high priority.
Also, when you have issues when making a call, do not look primarily at the phone's own outgoing traffic because it will likely be only the voice stream. Priorities are always relative, when there is only a single stream of data there is not much effect when changing its priority.
It would make more sense to look at the internet uplink than at the WiFi. E.g. when some other user or device is saturating the uplink with traffic, you can do something with priority e.g. using CAKE or a queue tree.
