Asterisk 20.14 Registration disappears

Asterisk Asterisk SIP
1

We have an odd issue that has only popped up on just one asterisk server, we have a lot of them, they are all identical in every way.

We’re running Asterisk 20.14.1 and without any indication in the error log, messages, or any obvious thing with the server itself, the PJSIP registrations just go away. Then they come back a bit later and it does NOT correspond with a ‘register’ event (we log these with AMI).

At first, we thought it was resource related as one time it happened we had a CPU core at 100%, but it keeps happening and with this exception we never see over 25% on a core (8-core systems).

I’m not even sure how to track this one down, been looking at the github issues and changelogs hoping to see something related.

Reiterating we have dozens of these identical servers and it’s just one of them that’s doing it.

Looking for guidance, big thanks :slight_smile:

BK

2

There’s not enough information. How is configuration done? Where are registrations stored? Are you referring to incoming or outgoing registrations? How are you seeing they are gone?

3

If they’re inbound registrations, is it possible that server has a network issue that’s causing it to miss client re-registrations in turn causing the registrations to expire?

4

These are very basic setups, just defined in pjsip_wizard.conf, registered contacts stored in astdb.

We have no way to know precisely when it happens so I have someone literally just watching. No hints of any kind in the logs. If we can catch it I’ll note the state of the astdb contacts. But like I mentioned, they come back without the endpoints registering, so I’m assuming at this point the contacts are still in astdb and it’s some kind of PJSIP issue.

I can’t say when it started, but we build 20.14.1 on 2025-07-04 so it’s been running a while now without issues.

We have no problem upgrading to latest 20.x, but I’d love to know what’s causing this.

There’s only 360 endpoints with registered contacts.

From pjsip_wizard.conf:

[endpoint](!)
type=wizard
accepts_auth=yes
accepts_registrations=yes
endpoint/context=predial
endpoint/rewrite_contact=yes
endpoint/direct_media=no
endpoint/rtp_symmetric=yes
endpoint/force_rport=yes
endpoint/send_pai=yes
endpoint/send_rpid=yes
endpoint/rpid_immediate=yes
endpoint/connected_line_method=update
endpoint/t38_udptl=yes
endpoint/t38_udptl_ec=redundancy
endpoint/t38_udptl_maxdatagram=400
endpoint/t38_udptl_nat=yes
endpoint/voicemail_extension=8500
endpoint/disallow=all
endpoint/max_audio_streams=16
endpoint/max_video_streams=16
endpoint/inband_progress=yes
aor/max_contacts=4
aor/remove_existing=yes
aor/remove_unavailable=yes
aor/minimum_expiration=60
aor/default_expiration=600
aor/maximum_expiration=3600
aor/qualify_frequency=30
aor/qualify_timeout=3.0
5

The registered contacts go away all at once, if it was just not getting the registration events it would be staggered as they expire (since they all registered at different times).

6

Exactly what are they watching?

7

We’re watching:

pjsip show contacts
database show registrar

And we’re also watching via AMI’s “PJSIPShowRegistrationInboundContactStatuses” in our software, which if I recall gets the data from PJSIP’s in-memory objects and not astdb.

To what end I guess to see what data is where, i.e., if it’s still in astdb and not returned from PJSIPShowRegistrationInboundContactStatuses then I guess that’s an indicator it’s a PJSIP issue.

This is one of those I don’t even know where to begin, any advice is helpful, thank you.

8

A start would be a debug log to see if there’s any lower level things.

9

Thanks, we’re efforting that now.

Just wanted to add that whenever the contacts are lost all at once and no ‘unreachable’ event is fired in ami. There are 691 registered contacts on this server (I previously mentioned a lower number which was wrong). The contacts register again at their expected interval and all is well until the next time it happens. Our registration default is 1 hour, we lowered it to 1 minute as a temporary stop gap until we can figure out what’s up.

10

Wow.

I’m posting this to thank the Asterisk team for always trying to help when likely they know us users are idiots most of the time.

On this issue, totally self-inflicted, I somehow stubled upon the what was causing it.

On this particiular server, one of our devs left some test dialplan entries that included this:

exten => h,1,DBdeltree(${UUID})

Where ${UUID} was empty after they stopped testing but forgot to remove this, so it just wiped out the entire astdb in one swoop every time a call was hungup from this rarely but occassionally used context.

There probably should be an empty string catch for DBdeltree() but that’s no excuse for our idiocy here.

With such a busy server astdb was repopulated so quickly before we noticed it was empty that we couldn’t catch it.

Thanks again for the help and so much for all the hard work you do.

Sincerely, a very embarassed team of devs that have been using Asterisk since 0.9.

1 Like
11

Glad to hear you figured it out!

12

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