This sounds like a typical NAT related problem, but there is not enough information to see what is going on. I’d first check the network settings of the virtual machine. If there is a virtual network instead of a direct connection, you might have an additional NAT barrier and that implies that some NAT table entries go away after a certain amount of time without any activity.
You could try to capture the traffic on the hypervisor to see what arrives here. In case you see the packets, you have found the problem. On the other hand, there could be something entirely different.
If it is a registration frequency issue, you are talking about a side effect of registrations in keeping NAT and firewalls open, as the registrar would force an acceptable interval for its purposes.
If it was to be an issue with NAT, any guidance on where to look at and how to fix would be appreciated. I’m in a home setup so using a regular ISP router/ap.
Well, then start with the next network device and continue until you see the packets. Of course, you could also start with the source and follow the path until you hit a device that does not see the packets.
Home internet services are not intended for the operations of servers, which is what is required for incoming SIP. The NAT issue is likely to be in the ISP provided router, specifically a short timeout on how long automatically created incoming port forwarding rules last. With a professional grade router, you would want to create static port forwarding rules, and not rely on their automatic creation.
The other risk is that they may be operating carrier grade NAT and sharing a small pool of IP addresses between multiple active customers. The problem then would be deep in their network.
Ok so it looks like implementing TLS in the Asterisk server as well as on the endpoints and VoIP.ms solved this issue.
I have to admit I played around a lot today but I am about 98% sure that it was the TLS that fixed it.
I went back to a previous snapshot on the VM without TLS, switched back VoIP.ms and endpoints to uncrypted and the incoming calls issue reappeared.
I then switched it all back to the TLS configuration and incoming calls do work after more than 10 minutes of inactivity. Will make some more tests with longer periods of time and update this thread if need be.
It will be TCP that fixed it. Routers know that TCP connections last until they are formally closed, so would be expected to keep NAT rules open for the whole connection. TLS runs over TCP.
I agree with @david551 that, if it works now, it was a side effect because now you are using TCP and that probably has a longer lasting time in the NAT table of your router.
If it’s fixed for you know, it’s okay - otherwise I would have suggested to decrease your expiration time in the registration section. Like really down to 60 seconds.