SIP-Calls over LTE drop after exactly 32 seconds (OpenVPN) - WiFi is fine
-
Traffic in both cases goes over the tunnel both SIP and RTP as I understand it? That's the only path it has to the PBX.
The SIP traffic has no way to know or care about the route the tunnel is using other than the MTU. I can't see what else it could be really.
If the tunnel does not fail the SIP is using exactly the same route, NAT, ALG etc.
Steve
-
I just noticed, this only happens for outbound calls from the softphone. Inbound calls are fine. MTU values are fine.
-
A 30 second state kill is an indicator of asymmetric routing.
-
Are you not using OpenVPN when connecting over wifi?
That would imply it's local wifi in which case many things will be different.Steve
-
@stephenw10 I'm using OpenVPN all the time. At no point is the phone directly connected to the local network of the PBX.
Besides that: I tried some stuff out today and it seems to be indipendent of LTE/WiFi. When I'm connected to my home WiFi, it works. When connected to LTE it's dropping after 32 seconds, same for my WiFi at work. So we'll have to drop the thought that it's only LTE, it's depending on the network.I just read asterisk logs and took a detailed look at the IPs. My LTE-ISP seems to use a NAT-pool and then assign local IPs to the phones connected to the network. So effectively he's using one WAN IP and is "splitting" it up for multiple end users. But since it's NAT, I'd guess that's where the problem is. I'll get in touch with my ISP and we'll see how it goes.
Regarding my WiFi at work, I'll take a look at how it's configured tomorrow and eventually try different WiFis, like McDonalds, Shopping Center etc.
-
About the only thing that could potentially be different there for the SIP connection would be the tunnel MTU.
A guess, try Do not fragment and/or Disable scrub
VoIP packets tend to be small, so neither MTU nor fragmentation would be an issue. For example, a G.711 codec (toll quality), produces 64 Kb/s or 8 KB/s. Packets typically contain 20 mS of audio or 50 packets per second. That means each packet will contain 1280 bits or 160 bytes, plus overhead. That's far smaller than the smallest MTU you're likely to find.
-
Is your home wifi where the pfSense appliance is? Is the pfSense appliance just used as a VPN server here?
The 30s time period and the fact that VoIP traffic is usually all small sure looks more like route asymmtery somewhere.
Steve
-
@stephenw10 No, my PBX is at another location. And even if it was, it would still be connected via VPN because of the way my network is set up :D I have a "Main"-Location, where all the servermagic happens and my home, which is a completly different story. Sorry for not clarifying!
-
Hmm, well if the SIP traffic is always over the VPN it's hard to see how the routing could vary.
But I would still be checking for any blocked traffic to/from the phone tunnel IP or to/from the PBX anywhere.
It really looks like a state expiring and that is almost always asymmetry.Steve
-
@Tenou said in SIP-Calls over LTE drop after exactly 32 seconds (OpenVPN) - WiFi is fine:
The VPN-Subnet is configured as “local trusted”
Not sure what you mean with 'trusted', but your VPN subnet should be added to a list of local networks in Asterisk. Then check your SIP signalling on Asterisk side.
I see no signs that pfSense has anything to do with your problem. Please read this and follow the link there.
