Reloading Asterisk Drops SIP Peers

Asterisk Asterisk Support
1

One of my Asterisk servers is running Debian 8 with Asterisk 11. When I make changes to sip.conf, extensions.conf, voicemail.conf, or a variety of other files, I could issue “service asterisk reload”, and it would reload and apply the configuration without interfering with any SIP registrations or active calls.

My newer Asterisk server is running Debian 9 with Asterisk 13. When I issue “service asterisk reload”, the configuration files are reloaded as before, however all active channels are dropped as well as all SIP registrations (asterisk -rx ‘sip show peers’ shows that no one is registered).

Did something change between versions in terms of how I can do a reload of these files without killing active connections?

2

Are you sure the Debian port of the startup files hasn’t changed from doing asterisk -rx ‘core reload’ to simply killing Asterisk and restarting it?

What happens if you use the Asterisk CLI to do the reload?

1 Like
3

I checked the init script on Debian 9, and it issues a “module reload”. The same thing happens on Debian 8.

I haven’t tried “core reload”, but I can give that a shot tonight after hours and see what happens.

I’ve tried “dialplan reload” (which will reload my extensions.conf file correctly without killing anything that I can see), and “sip reload” (which does kill all of the active SIP connections, so that’s not good).

4

core reload is from memory, and may be wrong or obsolete. If modules reload, without a module name, is accepted, it should be OK. What you don’t want is a restart command, or a kill.

5

Right, “core reload” is what happens in the init script in Debian 9 if I run “service asterisk reload”, but that’s what doesn’t work. That is, it drops all channels and kills all SIP registrations. So I’m trying to figure out how to reload configuration files without that happening, as I used to with Debian 8/Asterisk 11.

6

Specifically reload just the subsystem you need.

asterisk -rx ‘reload app_voicemail.so’

asterisk -rx ‘dialplan reload’

asterisk -rx ‘sip reload’

etc.

7

But how do I reload the SIP subsystem without dropping current registrations? In Debian 8/Asterisk 11, I was able to do that.

8

A SIP reload shouldn’t drop any active calls, I believe it will only cause asterisk to re-qualify your peers.

9

I’ll verify tonight whether it does or not. However, when I do a “sip reload”, followed by “sip show peers”, all of the peers that were registered are no longer registered. Wouldn’t that mean that any inbound calls wouldn’t make it to the peers?

10

After some testing, here’s what I’ve found.

Doing either “service asterisk reload” or “sip reload” at the Asterisk CLI will not drop active calls, but it will de-register all of the peers, and they are unable to receive inbound calls until some number of minutes pass and they re-register. But they are able to make outbound calls during this time.

So the question remains, how can I reload that configuration without de-registering the peers, as I was able to with Asterisk 11?

11

All of the Googling that I’ve done indicates others having this same problem, but with two distinctions:

  1. Everyone else having this issue is using real-time peers. I am not… all of my peers are defined in sip.conf.
  2. The others that have resolved this were using older versions that upgraded where this issue was patched.

I’m not sure if there’s a change between version 11 and version 13 that’s causing this, or if there’s a difference in the configurations and I need to change it somehow to make this not happen.

12

Hmmm I never thought of this like a bug, but could be. In my case doing a sip reload never drop calls, but it send the “qualify(OPTIONS)” and unregister the ITSP numbers everytime. But all of it are back immediately so I guess thats why I never consider this as an issue.

Can you share your sip.conf to check it?

1 Like
13

I have a similar issue with issuing ‘sip reload’ from the Asterisk console. maybe 2 or 3 seemingly random peers out of 100 drop off the ‘sip show peers’ list and I can see them re-registering soon afterwards when verbosity is 9.

14

You are correct, it does not drop any active calls when doing a reload. But it does make the peers unreachable. And they don’t instantly come back, they only come back when the client recognizes that the registration has expired and they need to re-register. So the phones re-register at random times after the reload, and it usually takes about 15-20 minutes before they’ve all expired and re-registered.

Here’s the general context of my sip.conf file (I left out the individual peers as that would be a security problem if I posted it here, but let me know if there’s something specific you want to see from there):

[general]
context=default
pedantic=no
vmexten=*97
transport=udp
alwaysauthreject=yes
allowguest=no
callcounter=yes
notifyringing=yes
notifyhold=yes
limitonpeer=yes
session-timers=refuse
tcpenable=yes
tcpbindaddr=0.0.0.0
nat=force_rport,comedia

jbenable=yes
jbforce=yes
jbmaxsize=200
jbimpl=adaptive

This is the same configuration I have on my Asterisk 11 server, where this issue doesn’t exist.

15

This may be a similar issue, but it’s definitely not the same. When I do a “sip reload”, all of my peer registrations drop out, and they don’t come back until the peer decides it’s time to re-register, which could easily take 15-20 minutes.

16

Huh, so you are using TCP and not UDP for your SIP traffic?

You could try and set maxexpiry to something like 300 to see if that helps the phones re-register sooner.

You could also try and set qualifyfreq to something like 120 to force asterisk to try and re-qualify your peers more often.

17

For some of it, but not most of it. Most peers are UDP, some are TCP. The issue affects them both.

I’ll give those options a try. But the underlying question remains, why do the registrations drop out? This is something new that I’m experiencing in Asterisk 13 that I did not experience in Asterisk 11 (or 1.8 for that matter). In those past versions, I could reload the SIP module, and it wouldn’t drop any of the registrations. That’s the behavior I’m looking for.

18

I haven’t been able to make any progress on this. Does anyone have any other thoughts as to why executing “sip reload” would drop the registration of all of my SIP peers?

19

Did you find a solution?

This stack overflow question seems similar and suggest looking at rtautoclear=no or rtcachefriends=yes

Ref: https://stackoverflow.com/questions/17035919/asterisk-sip-peers-lose-registration-if-dumped-database-reloaded

20

I have not yet found a solution to this. In the mean time, I’ve been working around it by making any SIP configuration changes and then doing “sip reload” after hours when it will have minimal impact.

The items you mentioned look interesting, however they appear to be for real-time peers, which I’m not using.

When I set up this server, I set it up using my previous Asterisk 11 configs as a base. I suspect there might be something in there that either doesn’t like Asterisk 13, or is otherwise causing this.

So my current plan for troubleshooting as soon as I can find a bit of time to do it is to do a fresh install of Asterisk 13 on a new server, set up a couple of peers (but otherwise leave the default config), and see if the issue exists there. I suspect it doesn’t, otherwise there’d be a LOT more people experiencing it and reporting on it, and I’m having difficulty finding anyone having this issue. If it doesn’t happen, then I’ll start comparing my configs to see which options are different, and then begin changing them trial-and-error style to see which one causes this issue.