Incoming Calls stops working after a few minutes


I’m running Asterisk 20.2.0 on Ubuntu server 20.04.5 in an Hyper-V virtual machine with a MicroSIP endpoint and as provider.

After booting up the VM, incoming and outgoing calls are working just fine.

However after around 10 minutes of inactivy, incoming calls doesn’t reach the server anymore. On the caller end there is not even a ring.

Asterisk CLI doesn’t display any warnings or error messages while trying an incoming call in this condition.

I used tcpdump on the VM to capture traffic and I don’t see any SIP packets exchange when this condition happens.

In call history I can see a corresponding unanswered call entry.

Outgoing calls do work all the time.

After either a restart of the Asterisk service or an outgoing call, incoming calls start working again until the next 10 mins or so inactivity period.

I also tried deactivating the firewall but the issue persists.

Any idea on the cause or a fix to this Issue?

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.

Are you sending registrations often enough? How does your registration section in pjsip.conf look like?

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.


Thanks for the quick replies.

So I captured the traffic at the hypervisor level and I don’t see any SIP packets when the incoming calls fails.

I also replicated the exact server config on a VMWare VM and I get the same problem.

As for the registration times, they match the stock pjsip.conf config. Here is the registration section :

193 [voipms]
194 type=registration
195 transport=transport-udp-nat
196 outbound_auth=voipms
199 ;contact_user=1234567890
200 retry_interval=60
201 forbidden_retry_interval=600
202 expiration=3600
203 line=yes
204 endpoint=voipms

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 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 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.

I appreciate the support you guys gave me!

Any ideas why TLS could fix this issue ?


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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.