Tell me about it. And that was just the beginning! I figured someone might benefit from knowing what is possible and some of the hurdles faced.
I've been testing with the Linphone application running on my windows 7 laptop. It is pretty resilient. Further testing has shown that when I have the OpenMPTCProuter serving my entire LAN network, and I'm connected over wifi with my laptop, I'm able to reboot the DSL router or the LTE router, and I only get maybe a split second robotic sound glitch in audio quality. The call and conversation continues fine. This is exactly what I hope will happen for the person in the house who is on the phone all day.BillA wrote: ↑Sun Jan 24, 2021 7:54 am I've noticed that a VOIP connection's reliability depends on several factors, which includes the VOIP provider's platform/proxy, the client device being used, and of course the internet connection. A call can drop at any one of those points of fault, and not necessarily due to the internet connection alone.
I've also shut down the VPN connection (running as a client on my laptop), and Linphone waits long enough for Windows to re-establish its IP address and routes, so the call isn't dropped. I didn't time it, but it was several seconds. Obviously, the audio is silent during that time period. Starting up the VPN client in the middle of a call results in just a momentary gap of audio.
Side Note: For anyone else wanting to test SIP, my setup is:
- Linphone app
- Free Linphone sip account
- Call this sip endpoint: sip:thetestcall@sip.linphone.org
Some of the features that test call system provides are:
- record yourself and play it back
- do a real-time echo test, where everything you say is played back immediately (to test latency)
- play music constantly.
That setup, without any commercial VPN, uses UDP, which OpenMPTCProuter then hands off to the Glorytun UDP tunneling module. I can see this in the UI: Status->Realtime Graphs->Traffic->tun0
I thought that was pretty efficient for VOIP, until I saw what the corporate VOIP was doing.
For the person in the house who is on the phone all day for work, their setup is:
- Company laptop connected over wifi to LAN
- Corporate VPN
- Citrix virtual desktops for all the applications (only thing that runs locally (at least I think it is local) is the Avaya telephony system). They lock it down so no other apps can access the internet, not even through the VPN. Everything must be done on the remote desktops. Doesn't seem like the most efficient approach, but that's how they have it set up.
I finally turned on OpenMPTCProuter when they were on a break from working. After they re-established their VPN connection (which may have been due to a timeout, not due to the network switch), everything worked fine over the OpenMPTCProuter system. VPN, Citrix and Avaya all worked.
They said that voice quality was fine. They have always had some latency with the above system, so even if this added a little bit more latency, it wasn't noticeable.
I wasn't able to test rebooting one leg of the WAN connections to see if the VPN and Avaya handled that. I spent most of my time trying to track down which interface their data was using in OpenMPTCProuter. Using some linux tools (iptraf-ng helped a lot with this), I was finally able to watch increases in packets, but *only* when they were talking or the person on the other end was talking. With Linphone, silence is sent, not just voice (from my end, not from the other end, with what I was connecting to).
It would appear the corporate VPN tunnel and the Avaya voip inside that were going over the same Glorytun UDP tunnel in OpenMPTCProuter. But the bandwidth was averaging between 1 Kbps and 10 Kbps. Hardly anything. I couldn't believe it was that efficient.
This is the traffic in the iptraf-ng for Linphone, *not* for Avaya, going through Glorytun:
Next step will be to reboot the LTE router and the DSL router (separately), when they are not on a call to see if the VPN can handle that. If that test passes, then I'll cross my fingers and do it when they are on a call.
Some of my early testing was calling a phone number that runs that same test call system, over wifi calling. My wifi calling is poor quality to begin with (combination of phone software and t-mobile probably), so I think most of my glitching was due to the wifi calling, not due to the OpenMPTCProuter setup. And I think I did most of that with only the DSL link in the equation, which is a slower link with only 0.8 Mbps upload speed. I don't think I've tried it yet over the dual WAN setup.
This whole thing is very complicated. This isn't for the faint of heart. I mean, some of the setup isn't too bad, but if you need to dig into it more, there is a *lot* going on under the covers. On the other hand, it provides redundancy/resiliency, in real-time, plus the extra speed of multiple WAN links. So what a person loses in speed of the VPN on top of it, they more than make up for in the extra WAN link, I'm guessing. I'm not sure how much latency the VPN adds on top. I don't think it is that much, since I've picked a VPS and VPN provider in the same large city, which is also where my LTE data enters the internet.BillA wrote: ↑Sun Jan 24, 2021 7:54 am Seem like running a VPN on top of OpenMPTCProuter is a little over complicated, giving you a hit on both speed and latency. There has to be a better way to bypass the streaming provider's IP security without having to use a clusterfuq of VPN's on top of VPN's. lol
You can bypass OpenMPTCProuter by going to: Services->OMR-Bypass. Depending on your network setup, this may or may not be easy. I have double NAT going on, so that complicates it, since the OpenMPTCProuter doesn't see my LAN IP addresses -- it sees them as the router's address between OpenMPTCProuter and the rest of my network. In my case, however, I don't want to bypass the OpenMPTCProuter solution for streaming. I'd have to set it up for every streaming device (TVs, Rokus, etc.), and then I'd have to choose either a difficult destination based rule for putting streaming content out a regular WAN link, or a simpler, source IP based rule, which would mean phones and computers wouldn't benefit from the added speed of the multi-WAN connection. And streaming wouldn't benefit from the multi-WAN connection either (at least not in an aggregated sense).
Having said that, I'm very open to other ideas, if there is some other way to fake out the streaming providers. I'm guessing there are probably some VPSes they haven't caught onto yet, so that might be one option, but I'm also guessing they don't advertise this, for obvious reasons.
Having a VPN client running on the VPS server, so the multi-path stuff is chained to the VPN, instead of them being used over the top of each other, would seem to be more efficient. However, that would it much more difficult to route something through the multi-path link, but *not* through the VPN. It would all be based on target addresses, not source addresses, since i'd be very divorced from my LAN by the time the packets came out the other side of the VPS software. I did open a ticket on github for OpenMPTCProuter, to see if I could get help chaining it this way, however.
I tried running the VPN client on the OpenMPTCrouter device, but I couldn't get it to work properly. The VPN came up, but the firmware didn't route my traffic over that VPN tunnel, on top of the multi-path link. I'm thinking maybe it only has openvpn capabilities so that it can use that as a different option for its own tunneling, not for a commerical vpn to be used like the way I'm trying to do. I asked about this in the ticket too.
I did get the commercial VPN tunnel running in my router that is running Tomato, that sits between OpenMPTCProuter and the rest of my LAN. But that is an old linksys E3000. It doesn't have the horsepower. My speeds were very slow on speed tests and I traced it back to maxing out the CPU in that router. It did work, however, and Netflix, Hulu, etc. were happy.
I have to decide if I want to run a VPN client on a device that can handle it, on the LAN side of OpenMPTCProuter, or if I want to try to get the VPN client to chain together with the OpenMPTCProuter server software in the VPS. There are pros and cons to each.
I probably won't benefit from 5G, directly, for some time, where I'm located. The higher frequencies won't reach my house, so I'd need them to roll it out for the lower frequencies here. I could possibly benefit from the other 4G features that the 5G modems have, however, regarding greater carrier aggregation, more MIMO, etc. But given the costs of the modems right now, I think I'll invest in better antennas and a less expensive 4G modem for my second LTE connection. When 5G modems come down in price, I'll look into upgrading to see if I can take advantage of the better 4G features. That will give the providers time to add support for greater CA and MIMO in the towers too.BillA wrote: ↑Sun Jan 24, 2021 7:54 am Also, upgrading to a 5G modem would not only improve your speed and throughput for your family, but also reliability. You may not have 5G service in your area yet, but rest assured it's coming soon to a tower near you (in that creepy movie announcer guy's voice... muaahh!).
If you're saying that a different modem might not drop connections, so I wouldn't need all this other stuff for reliability, that is something I've considered. I may go with a Quectel modem (currently using a Sierra). That, combined with a beefier router based on different hardware might make a difference. Some of the disconnects are due to router firmware crashes (more rare). Others are due to the modem being disconnected and the router having to start it up again. Whether that is due to the tower doing the disconnect, or modem firmware, or router firmware, or router hardware, is an unknown.
*If* my second LTE system doesn't show this problem, then I can route the work computer through its connection and use the multi-path stuff for the rest of the house for the added speed.
At the end of the day, the multi-path speed does come with a lot of other complexities and side-effects that people need to be willing to live with.