WiFi Calling Priority

[eightball]

Hi,

Can anyone share a setup to prioritize wifi calling (apple on UDP 500 and 4500) for a selected WAN on a dual WAN setup that is currently using lowest latency as the default and only rule? At the moment this is my outgoing rules table:

rule____________________algorithm_______source____destination_____port
https persistance auto____persistance auto____any________any_______tcp 443
default________________lowest latency

[MartinLangmaid]

Hi - welcome to the forum!

Why do you want to prioritize wifi calling - is it not working or failing?

[eightball]

Hi, this is a somewhat of a non-typical situation. This is a rural residential application where we rely on one system using fixed point to point wireless (WAN 1) and a second system using LTE (WAN 2). Both are limited to about 20 mbps
max, with sometimes dropping to 5 mbps. The LTE system also locks up (I believe by design of the provider) and requires regular automated reboots. With this, I can have some challenges with wifi calling dropping or poor quality mid-cal. We use wifi calling
for our phones due to poor cell reception. I’m quite confident that the point to point wifi WAN 1 system should give me more reliable results and wanted to create a rule for that purpose.

[Don_Ferrario]

Wifi calling over an LTE data source won’t be pretty. Latency is poor and usually inconsistent. To prioritize traffic to WAN1 you’ll need two rules:

source = any
destination = any
protocol = UDP
port = single port 500
algorithm = priority with WAN1 first

Then another rule with the port = 4500.

The rules as described will prioritize all traffic on those ports to WAN1. If the Apple server has a specific IP address or subnet and you can figure that out from the sessions table you can change the destination to that subnet. There likely is no harm to sending all UDP 500 and UDP 4500 through WAN1 so what I wrote above may work fine.

These routes must be above the routes you already have. The table works by reading from the top, stopping at the first rule that matches.

[eightball]

Thank you. Can you please clarify if these two new routes should be above the https persistence rule or one below it?

[Don_Ferrario]

The new routes must be above the persistence rule. The router will evaluate the table you build starting at the top. Once a match is found, the matching rule applies. Traffic that matches UDP 500 and UDP 4500 will be handled using those rules. Once a match applies the table exits.

Traffic that does not match will fall to the next rule in the table which in your case is persistence.

[mystery]

Looking to pick everyone’s brain…

Users have AT&T and Verizon Wireless cell phones. We have little-to-no cellular signal in some locations so use the cell phones with WiFi calling enabled. Despite establishing a Speedfusion connection and enabling smoothing, we are still having issues with calls dropping, during WiFi calling. Interestingly, the calls have issues even when we have three active WANs and only one WAN may lose connectivity (I would think one of the other two WANs should’ve kept the WiFi call going).

Would enabling FEC (forward error correction) help? Would increasing the Smoothing percent help? Should I create any firewall or QoS / priority rules? What does “receive buffer” do? Smoothing cap?

I am guessing it will be hard to keep up-to-date on VZW’s & AT&T’s WiFi calling service destination (IPs) but perhaps they use a short # of ports?

I dont necessarily want to increase Smoothing to 400% and cause so much additional duplication of packets that my bandwidth usage sky rockets (especially on our cellular link). So I am thinking to create a sub-tunnel/second Speedfusion tunnel and just use an outbound rule for those specific WiFi calling ports so the FEC/Smoothing at 400% only happens for WiFi calling and all other traffic originating from the cell phones does not cause extra packets to be duplicated thus causing bandwidth usage to skyrocket? (some users do a significant amount of video streaming from their cell phones so dont want them eating up bandwidth as the packets are duplicated via smoothing at say 400%).

Any other settings I should try tinkering with on the speedfusion tunnel/Fushionhub Solo/IC2/device itself? I am still confused why with at least 1-2 good / stable WANs the calls drop.

Thanks!

Edit: so every time the cellular link goes down, I lose the WiFi Call. I have checked my Speedfusion WAN priorities are all 1, they are all 1 on the MK2, so I dont know why 1 WAN going down when there are 2 other WANs active/working causes the call to drop? I even tried setting Smoothing to 300% and FEC to high, as soon as I move the cellular to disabled on the MK2, the call drops. I tested placing the WiFi calls with the WiFi As WAN links up and it works over them so its not like they aren’t working with WiFi calling. Something is amiss…

[mystery]

So this is interesting, I think the session you see here is the WiFi call… I don’t know how/why its breaking out from the Speedfusion Smoothed tunnel to Cellular WAN directly?

[C_Metz]

Make sure your Advanced → Service Passthrough → IPSec NAT-T is disabled

This feature makes sure that when someone starts an IPSec negotiation on port 500, that it uses the same WAN connection for the subsequent connection on 4500

[mystery]

Wow, hours of playing with settings, and that may be the ticket! Thank you!!

Seems to be working now and all WiFi calling traffic is going over the Speedfusion Smoothed Tunnel

I am still confused how it would even break out directly to the Cellular WAN to begin with?

Also, any other ramifications from disabling this setting?

Any impact to ability to connect to VPNs or anything on end user computers etc?

Thanks!!

[C_Metz]

Here is the design of that setting… say you have WAN1 and WAN2 and you set the connections to balance across the 2 WANs. If a PC starts a VPN negotiation on port 500 on WAN1, then starts the conversation with the VPN on port 4500 on WAN2, the VPN at the far end would disconnect you because it see 2 IP addresses… so this rule goes into affect before your outbound policy to ensure that scenario doesn’t happen… and as you saw it’s enabled by default to protect you from yourself. Now that it’s disabled… it’s on you to ensure you write your outbound policies such that port 500 and 4500 coming from a computer go outbound using the same IP address.

[mystery]

Thanks but I am curious how my WiFi calling was starting / negotiating on port 500 to begin with?

Below are my rules (aside from some custom camera entries):

Rule #1
Source: Any
Destination: Any
Protocol: Any
Algorithm: Priority
Highest priority: Speedfusion VPN
Not in use: All other WANs
When no connections are available: Fall through to next rule
Terminate Sessions on Connection Recovery: Enable

Rule #2
Default rule: Custom
Algorithm: Fastest Response Time
Connection: All WANs checked
When no connections are available: Drop the traffic

So how would you recommend making sure port 500 and 4500 go outbound using the same IP address?

[C_Metz]

I suspect given the complexities of SpeedFusion and it not being considered by the system to be a True “WAN” caused that IPSec setting to send your Traffic to your first listed WAN connection.

That fastest response time rule could cause you VPN trouble if your tunnel ever goes down. That rule essentially sends requests out both WANs and accepts whoever responds first, which means the VPN out on the internet would see 2 requests from different IP addresses, which could cause you issues… but only if your tunnel is down. Might want to put 2 rules in between those enforcing your 500 and 4500 to a specific place… of just take the risk that if the tunnel fails, VPN connections will fail.

[mystery]

Thanks, I submitted a ticket asking Peplink team whether it is by design or a possible bug. I think I read in the past, they have said that a Speedfusion tunnel should be recognized as a WAN. I do see that there is an Expert mode on the Outbound rules and that is where perhaps that setting comes into play at a higher priority than the Outbound rules that I have created?

I think the way my configuration is set, by default all traffic is not over the Speedfusion tunnel and I am only directing it to go over the tunnel via the Outbound rule that I shared above. Is it worth considering enabling the setting “Send All Traffic To Remote Hub” so all traffic is via the Speedfusion Tunnel by default and then I can have Outbound rules that remove some devices from using the Tunnel (basically opposite of what it is now)?

Back to my earlier question: how would you configure Smoothing? Is there any value in:

• Enabling FEC (forward error correction)?
• Would increasing the Smoothing from 100% to 200%, 300%, or unlimited be of any use?
• Should I create any firewall or QoS / priority rules?
• What does “receive buffer” do?
• Smoothing cap?
• I set the max latency diff to 150, should I lower it to 75 or set it to something else (default seems to be 500)? Some WAN links sky rocket in latency when running speed tests it seems.

I currently have Smoothing set to 100% and FEC set to low. I can leave as is and see performance or remove FEC. The issue is my WANs can be unstable but between the three, usually there is at least one good one. Just looking for an optimal setup.

Thanks!

[C_Metz]

I’m going to try and give my opinion on each option. Then at the end I’ll tell you what I’d do for pure VOIP only.

1. FEC → Used when WAN Smoothing is too costly… I use this for my wife’s constant work video calls. This combined with a 2 second “Fast” failover time on the SpeedFusion tunnel is enough to where she doesn’t miss a beat when a WAN goes offline. I would only use FEC if you can’t afford WAN Smoothing. IE her video calls are about 4.5GB per day worth of traffic and I don’t want to replicate that to other WANs… Versus my xBox generates 250Mb worth of traffic a day, so I use WAN Smoothing for it because I don’t mind replicating that amount of traffic and I want the lowest possible latency for gaming.
2. WAN Smoothing at normal is good for almost all cases, unless you commonly have 2 WANs having issues at the same time. If you have 2 bad WANs and need traffic to replicate across a 3rd connection, then I’d go for something like MAX
3. If you have others on the same network using things like Netflix or downloading large files and you don’t want it interfering with your VOIP, I would absolutely enable QOS and tell it all VOIP is highest priority IE. gets to cut in line.
4. Receive buffer is useful for out of order packets, and if you are seeing a ton of those and hearing garbled speech in your VOIP calls, then I would consider this, but for most cases, purposefully adding latency is not needed.
5. Smoothing Cap?
6. Latency Diff setting… here’s how I did mine… Go to the SpeedFusion status tab and watch the 2 connections… note the lowest and highest value you see under “normal” conditions… obviously if it’s spiking to 500ms you ignore that. So for me this results in 82ms and 24ms as the lowest and highest values I saw under normal operating conditions. This gives me a diff of 58ms… so I set my cutoff at 75.

So if we are just talking about pure VOIP traffic (64-128kbps) and nothing else… WAN Smooth it across all 3 connections (MAX), turn off FEC, erase the Latency Diff Cutover. If you have other traffic involved then refer to the answers above

My own setup…

1. PC’s and iPhones go direct to WAN for fast downloads, as well as 2 Tivo’s for watching Netflix.
2. xBox goes to a WAN Smoothed tunnel for low latency (tunnel #1 because of inbound)
3. All other traffic goes to a Bonded Tunnel #2 — 2 second “Fast” failure detection, 75ms Latency Diff Cutoff, FEC Low. This is Alexa’s, smart lamps and plugs, wife’s work PC, Smart TVs.

[mystery]

Thank you very much for the explanations. I will have to digest. It sounds like I should give some more thought to how I am handling WiFi/VoIP calls versus video conferencing versus normal internet traffic.

My highest priorities are keeping WiFi calling, VoIP calls, and my video conferences going. Sounds like I might not need to use Smoothing for my Video conferences though and FEC with a Fast failover time may be sufficient. I was originally thinking of moving my cellular link to Priority two as there are two WiFi as WAN but then that would impact my WiFi calling and VoIP calls that I dont want to disconnect when/if the WiFi as WAN links degrade.

So you created several Speedfusion tunnels? One for video conferencing with FEC but not smoothing, one for smoothing, and any others? How did you section out / set rules for the video conferencing? I use Webex, Zoom, Skype, and Teams. Did you have to get all the destination IPs/hosts and create rules for them to use the sub-tunnel that only had FEC enabled?

As for enabling QoS for WiFi calling and VoIP, is that done at: Advanced > QoS > Application ? For WiFi calling, do I have to figure out the destination hosts/IPs/ports and enter those in somewhere?

Some devices that do video conferencing (i.e. computers) currently are using the Speedfusion Smoothing tunnel and the problem is not only that video conferencing eats a lot of bandwidth but those devices also stream video (Youtube, Netflix, etc). I was able to cut down on bandwidth usage by routing security cameras and dedicated streaming devices (i.e. TVs/Roku) directly through the WANs that are not cellular (and not through the Speedfusion tunnel) so that was a big improvement. Just trying to further refine things now.

As for Smoothing cap, please see this screenshot:

[C_Metz]

Smoothing cap inter-plays with the Smoothing level when you have a many to many tunnel, but you have a 3 to 1 tunnel, so I don’t think it matters. If you tell WAN Smoothing to triple bandwidth 300% and set the cap on high it will replicate to all 3 WANs.

As far as multiple tunnels…

Then you can do this…

Then steer traffic…

As you see, steering traffic is easy when one device needs one set of behaviors, but when one device does multiple things like my XBox… which needs Netflix, Amazon Video, Inbound Open NAT, and Gaming… well I have 8 rules written just for it’s traffic.

Rule #1 allows me to talk to an upstream Mofi when it’s WAN is listed as offline
Rule #2 keeps ISP’s from snooping my DNS lookup by throwing them down the SpeedFusion tunnel
Rules #3-10 are the annoying XBox that does everything
Rules #11 Tivo’s for streaming
Rule #12 PC’s and iPhones
Rule #13 Wife’s Work PC
Last Rule #14 send it all to the bonded tunnel