Asterisk 20.11.0 goes idle after ~10hrs post reload

Hello,

I am running Asterisk 20.11.0 with PJSIP.
My issue:

  • When I reload Asterisk (core reload or pjsip reload) in the morning, it works fine all day.

  • But by the next morning (~10 hrs later), the system is idle:

    • core show channels shows nothing.

    • Trunks/endpoints don’t seem to handle calls.

    • I have to reload/restart to restore traffic.

Notes:

  • No obvious errors in /var/log/asterisk/full.

  • This seems related to trunks losing registration or PJSIP session refresh.

  • Using [flat config files / Realtime DB → add your case here].

Questions:

  1. Is this a known issue with Asterisk 20.11.0 PJSIP reloads?

  2. Could this be due to trunk registration expiry or NAT timeout after 24 hrs?

  3. What is the best practice to safely reload configs without causing idle state?

Thanks in advance!

You could answer this question yourself by looking at the issue tracker. The answer is no, though.

It certainly could - so you need to investigate. If you’re doing outbound SIP registrations, are they registered? Do you see any SIP traffic?

There is no “best practie”. Reloading is a safe operation.

I see you neglected to finish filling out your AI generated forum post.

Do note, statements like this rely on YOUR understanding of things.

1 Like

On Thursday 21 August 2025 at 10:17:28, manojgowda2520 via Asterisk Community
wrote:

  • When I reload Asterisk (core reload or pjsip reload) in the morning,
    it works fine all day.

  • But by the next morning (~10 hrs later), the system is idle:

I don’t understand the timing. You say that you reload Asterisk “in the
morning”, and that “by the next morning” you have the problem.

How is one morning ~10 hours later than the previous one?

  • No obvious errors in /var/log/asterisk/full.

  • This seems related to trunks losing registration or PJSIP session refresh

What makes you say that? What have you seen (especially if there is nothing
in the log file) which makes you think registration is getting lost?

Antony.


International affairs can be complicated.
On 28th June 1914 a Serb shot an Austrian in Bosnia, so five weeks later
Germany invaded Luxembourg, declared war on France, and then invaded Belgium,
which caused Britain to enter the war.

My immediate thought is that you are relying in frequent calls to prevent a rule in a router timing out, and there are long enough gaps overnight, for the timeout to occur. If that is the problem, the answer is to make the rules in the router static.