We have the server and all the wired extensions on the same dedicated subnet. What we are having is that certain extensions lose their registration and then re register. I know that it is not a network problem because the other line that is registered on the same phone does not do that. The voip phones on the cell phones (via wifi on the same subnet) unregister sometimes, but that is understandable since they come into and out of wifi service. It is not the same phone all the time, and seems to change when ever asterisk is reloaded.
Does someone know where to start looking for the problem?
@jmmicmc First, it’s good to hear the problem went away. Second, the next time this or any other issue arises some actual troubleshooting should be involved. Do NOT just downgrade your Asterisk version as the first step to an issue. That is not the right solution or answer to any issue.
@dolesec Please do not suggest downgrading version without actually knowing details and doing troubleshooting first. As previously mentioned it is not the right solution or answer to any issue as the first step.
@jmmicmc Also, it could be a network issue. If you are running multiple extensions on the same phone and do not have them using unique SIP ports it will cause a conflict and could very well cause the issue you are having. Again, proper troubleshooting should be implemented to determine where the underlying issue really is.
@BlazeStudios, you are correct it could be lots of things, but there is a known issue with Asterisk 11.20 that pretty much exactly reveals itself as the complaint identified by OP. The fix is to downgrade until 11.21 is available for the Distro (or switch to Asterisk 13). In this case the forum users get the benefit of @dolesec’s experience as the head of Sangoma’s FreePBX support team.
gotta love how Schmooze pushes out fully untested updates both to Asterisk and surprisingly FreePBX itself, ( oops I guess I’ll get flack for that ) Maybe there should be a two level track, one that is proven working, and one that is best effort so far, call that alpha,beta or gamma. . . . delay that best effort solidification for a month or two until it is actually proven working.
“In Asterisk 11.20.0 chan_sip looses registrations of some IP-phones (on several different systems) after a while. In Asterisk the phone then shows “unreachable”, while the phone’s status shows “Registered”. Reverting back to Asterisk 11.19.0 solves the problem. The phones are mostly Yealink phones, different models with different firmwares on different systems, none of the phones firmware was recently upgraded. Dis-/enbling the phone’s SIP account or rebooting the phone makes it work again for a while, but then Asterisk shows the phone again as unreachable.
I attach a SIP trace of a Yealink W52P DECT base with 2 handsets (331/332). “qualify=yes” is enabled, after a while Asterisk stops sending Option packets to ext. 331 while keeps sending packets to 332.”
@dicko - as Lorne described this is a tricky one - i’ve only seen it 4 times but each of those were resolved with the downgrade; asterisk-version-switch makes this trivial …
Hi, I also have the same problem and described it in details (with logs and configuration) in this thread enter link description here I have one question to @dolesec if I downgrade an Asterisk version by this way, will I be able to update to a newer version in the future? I mean, could I use the upgrade scripts provided by FreePBX in the future? I’m afraid that maybe something will be broken in automatic update functionality.
@lgaetz Many thanks, you’ve really helped me, I’ll downgrade the version tonight as my users are gone crazy. When they’re waiting an important calls, I’m restarting phone to be able to receive them just right before the meeting time. Thanks God that they do understand an issue and are waiting for the fix patiently
I’ve just downgraded Asterisk version to 11.19 with the command: yum downgrade asterisk11*
After this, I’ve restarted entire server, I’ve check several calls to problematic extensions, but so far they continue to stay online/registered. So, I can say that the problem had gone … BUT, not I have other problem due to that downgrade, though it’s not so critical, but anyways, I really want to fix everything. Fail2ban service has gone crazy, it won’t start automatically and when I try to start it manually, it gives me the following error:
Starting fail2ban: ERROR Found no accessible config files for 'filter.d/freepbx' under /etc/fail2ban ERROR No section: 'Definition' ERROR No section: 'Definition' ERROR Unable to read the filter ERROR Errors in jail 'pbx-gui'. Skipping... [FAILED]
I looked into jail.local config file and yes, there is a section called - pbx-gui and the filter name really is freepbx, but there’s no such file into filter.d directory. First I thought that downgrade process might had deleted that file some how, but I have daily backups of VMs, so I restored entire /etc/fail2ban directory from the backup, but there is not neither. How did it work? I am not an fail2ban expert, but I do understand how linux and its configuration file does work… Well, I just set enable parameter to false (only under pbx-gui section) and I started fail2ban service without any issue. I check also in system admin module and it gave me the correct status, that it’s running. But I did read comments into config file saying that it’s an automatically generated file, so after I stopped it and then start again (from system admin module) it failed again, as the parameter still was set to enable.
Can someone suggest me how can I fix it and why did it broken?
This issue persists on up to date system, downgrade no help for me. It seems to be linked to particular extensions which have no obvious differences. I am going to try hardware swaps next, but these are all same firmware/batch. Yealink. t46g
It would be nice to use something like the monitor trunk failures option (but on extensions) to watch/track them, might also lead to more input as to the cause , if any