Problems with WiFi calling

Adrian4
Head in the Cloud

Problems with WiFi calling

Hello,

 

I have been getting complaints about call quality when people use their mobile phones on "wifi calling".

We have multiple large factories where cell reception is poor so people rely on the wifi.

Annoyingly, I have done several walk around tests, thinking maybe it was AP handovers that caused the issues but I had multiple perfects calls wandering all over the area people say there is an issue.


I was reading this guide - Wireless VoIP QoS Best Practices - Cisco Meraki Documentation
and it says in traffic shaping to set all VoIP and video conf to DSCP 46 EF voice comms

I am currently using AF41 which I assumed was the highest priority low drop queue there was.  We don't use any other traffic shaping other than the defaults so i assume it doesn't really matter which priority queue is used but i just wanted to check.


Also, the guide suggests a separate SSID for mobiles - is this just to guarantee bandwidth? because I don't thank that is an issue currently and Id like to avoid an extra SSID if possible.

thanks,

2 Replies 2
ConnorL
Meraki Employee
Meraki Employee

Wi-Fi calling relies on an IP-Sec tunnel from the handset to their carrier's network (See non-Cisco/Meraki link) so your QoS profiles won't actually influence it. IP-Sec doesn't like a blip in loss, which is likely what's happening as users roam.

 

Considering enabling 802.11r for smoother roaming and ensure you've had a site survey done to prevent any coverage gaps.

GIdenJoe
Kind of a big deal
Kind of a big deal

QoS will only do you any good in cases where you have high channel utilization.
As @ConnorL suggests you may have a poor roaming experience.  So if your Wi-Fi is using any kind of enterprise based authentication then 802.11r is a must.  However if it is a simple open or WPA personal kind of network then you could have bad spots in your Wi-Fi where you don't have enough dual AP coverage for handovers between AP's.

Keep in mind that it simply can also be a client specific issue.  So testing with multiple clients is a necessity.

As far as the QoS goes:
- If you can identify the downstream traffic of Wi-Fi calling you can add them to a QoS rule in your dashboard configuration.  Make sure you set layer 3 marking DSCP to EF (expedited forwarding) and if you hopefully are tagging your user traffic with a VLAN tag you must also add the PCP tag of 6 which will add that traffic to the voice queue.

 

For upstream traffic you can't do anything since it's the clients that have to tag their own traffic before sending it upstream.  So you could only verify this by doing several captures over the air and try to identify the voice packets (which won't be easy).

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels