SIP registration phones not rocksolid


When starting/restarting asterisk (v18 up-to-date), I encounter most of the time issues with registering the extensions. If so I restart asterisk via FWconsole restart and check again until all extensions are up and running. (after 1 or 2 times restarting). Then everything works fine for a while (2-3 days) until extensions are starting to fail register again. Until now, I don’t have a clue why.


Due to the fact that besides an asterisk setup, I do have voip at home using port 5060 already, so for this setup I configured sip-port 6111 for all phones (3 SPA 941), as seen in the screenshot below

Strangly each extension uses a different port when connected, but I don’t care (but maybe is an issue?)


Asterisk full log (available until 28 april 2023)

In this logging are 2 attempts included. In the first attempt ext 701 didn’t register but did when rebooten

Any help very much appreciated

First of all, it looks like you are not using Asterisk but FreePBX which is based on it. It may be that the fpbx forum is more appropriate because the people who are here don’t necessarily know the configuration details of fpbx.

Next, you should show the actual error and warning messages. It’s not like if something doesn’t work, there’s a unique way to configure it. Without reasonable error messages one can only guess.

Last but not least, it looks like you have 2 or more NAT Barrier. Whether the dynamic name resolution works or not also depends on the pjsip configuration parameters. It is conceivable that Asterisk gave up before the system got the new IP address when the external address changes.

But it could also be that you register the Fritzbox on the fpbx system. Then you would have to look at other things. But we have no information about that.

@ EkFudrek: Your conclusion that this is FreePBX is correct but I posted it here because it has more to do with the behaviour of asterisks (connecting extensions thru firewalls, assigning SIP ports to extensions and keep them alive). In my opinion that is the same for both solutions but I expect more experts here (just a feeling without hurting others).

In respect to the actual errors I can be clear… I don’t know how to interpreter this logging. I did look into it and for example I see that an extension like sip:701 suddenly is no longer handshaking with the server anymore. The reason for that is not mentioned in the logging (or I can’t find it).

The Dynamic Name Resolution should not be the issue. Reason for that is that the IP-addresses used hardly change, dyndns is updated every 15 minutes (although the server ip address only changes when I reboot my fritzbox), BUT the extensions on location 1 and 2 have (for the moment) a maximum server connection time of 3-7 days) and the disconnect appears to be random (daytime or nighttime). The internet infra is very stable in these areas.

My fritzbox doesn’t register on my server in this depicted solution. I do have separate voip nummers active (via 5060 in the Fritzbox and SPA 3000 on port 5070), but these should not be the problem.

Some extra information: It used to work for 2 to 3 years hardly without an issue. It started suddenly about a year ago without a cause that I’m aware of. Maybe it has something to do with replacing the router on location 1, but location 2 always has been less stable ( a backup phone on a second location in case).

Find inserted the SIP settings per extension.

And my general sip settings

Please provide configurations (and logs) as text files, not images.

You should no longer be using chan_sip, and there is little chan_sip knowledge left here. chan_sip has been removed from the development version and will not be in this years release.

Setting a port with host=dynamic is not normal, and might have no effect.

I’m unable to download the log without accepting a browser extension from the site, which I’m not prepared to do. The standard pastebin site works well and when it is up, the freepbx pastebin site is probably better, even though this isn’t a freepbx forum.

I can’t see where you have set your local networks.

I agree that you should be asking this on the FreePBX forum, not here.

The Dynamic Name Resolution should not be the issue.

Dat kannste knicken. If you have a Deutsche Telekom internet connection and not a fixed IP, then the IP changes about every couple of months. If you have a Vodafone (or was it 1&1?) connection, then it still changes every 24 hours, preferably when this causes other problems.

If you have set up your registration parameters such that it re-registers for a few times after something like 60 seconds, then you are out of luck with your DynDNS setup. Again, we don’t have enough information to judge and I don’t know what FreePBX would configure here for a PJSIP account. You are in limbo with CHAN_SIP anyway, as David wrote correctly. It’s not that CHAN_SIP is bad, but you need to know what you are doing.

3-7 days might indicate a subtle NAT problem. AFAIK, Futzbox does not allow to collect meaningful pcap traces. You might look at the SIP traces of the PBX, but to get started it might be easier if you happen to know what enters the fishbox.

It means nothing if it worked years ago. Firmware, system software, Asterisk FreePBX might have changed somewhat. Even your service provider might have made things a little bit more secure, such that your configuration has to change a bit.

Depending on the (German or French) service provider I have come across a lot of funny things in the past, which required some ugly tricks for CHAN_SIP. PJSIP is generally a lot more straightforward.

@david551: There is a reason why I stick to the chan_sip driver. These phones (SPA 941) don’t seem to support chan_pjsip driver (simply too old). I wouldn’t accept any additional extension either (but I was not aware, simply looking for a quick solution because this file can be attached.

Found a better place for this.

Let me know which files are missing and I will supply these…

The only reason a phone wouldn’t support it is that the phone’s implementation of SIP is broken.

Thanks for your feedback… This is a NL setup, but I agree that these providers are changing also constantly without mentioning what they are doing/implementing. And indeed, updates in firmware, software or services are an unknown characteristic in this analysis.

Ouch! You are trying to use end of life Cisco phones in a complex, multi-vendor, NAT environment.

Cisco phones have a reputation for only working well in a non-NAT environment, with other Cisco devices.

Let me look into it… It works with the SIP driver, but not with the PJSIP. But it can be a user problem (after all). For the moment If I use PJSIP the phones does register at all.

Enabled the PJSIP driver for 1 linksys SPA941 and so far it works within a local setup (within the building). I checked the NAT settings for the phone on location 2 and enabled the NAT to see if this improves the stability.

Be aware that the connected routers and/or firewall also do play a role. It is usually better to diagnose the traffic before any device and then decide what to do.

There could be another problem with your setup as your phone connections do not seem to be protected in any way. In a business environment this could also lead to legal problems. It may be easier to use a LAN-to-LAN OpenVPN or WireGurad VPN tunnel.

The Linksys phones might have a NAT option, but you do not know what it is actually doing (unless you monitor the traffic).

Thanks for the feedback. I don’t foresee any legal issues here. Very low volume solution and no external parties (customers). But indeed a bit complex because it is a mix of locations, hardware used, freepbx /asterisk and too many settings (but persistence prevails when all else fails)

With the updated NAT setting in the phone I do see an improvement in stability. It’s now 6 days without an issue, where the issue would occur within 3 days. Fingers crossed

I think we can close the topic. Analyzing the NAT change on the phone, I see a huge improvement, because the issue seems disappeared. I’ve a stable connection

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