Extension insists on forwarding calls

PBX = 14.0.16.9
Asterisk -= 13
Zulu = 14

We have a single extension that is unconditionally forwarded to another extension. Using *73 had no affect. I went into the UC and saw that it was forwarded. So I attempted to remove the forward by clicking on the button. It changes to Unforward and within a few seconds it reverts back to forwarded. Since th euser of that phone is no longer using ZULU I removed that user in Zulu., Restarted Zulu. You guessed it the phone is still forwarded. My next trick is to do a core restart. Other than that I am at a loss as to what might be going on. Anyone have any ideas??

Thanks

I’d start by putting in a support ticket. This sounds like a bug and bug reports are free.

Unless other reports come forward or this is reproducible, it’s premature to open a bug. This sounds like AstDB or possibly disk corruption. Are you seeing any other symptoms or oddities?

We had a DB lock error last week and restarting Asterisk appeared to clear it. All the extensions went offline until it reset.

Got this in the Fail2ban log:

[2021-06-22 09:15:10] WARNING[9586][C-00000025] db.c: Couldn’t execute statement: SQL logic error or missing database
[2021-06-22 09:15:10] WARNING[9586][C-00000025] func_db.c: DB: Error writing value to database.
[2021-06-22 09:15:10] WARNING[9586][C-00000025] db.c: Couldn’t execute statement: SQL logic error or missing database
[2021-06-22 09:15:10] WARNING[9586][C-00000025] func_db.c: DB: Error writing value to database.
[2021-06-22 09:15:10] WARNING[9586][C-00000025] db.c: Couldn’t execute statement: SQL logic error or missing database
[2021-06-22 09:15:10] WARNING[9586][C-00000025] db.c: Couldn’t execute statement: SQL logic error or missing database
[2021-06-22 09:15:10] WARNING[9586][C-00000025] db.c: Couldn’t execute statement: SQL logic error or missing database
[2021-06-22 09:15:10] WARNING[9586][C-00000025] db.c: Couldn’t execute statement: SQL logic error or missing database

Also:
[2021-06-22 09:17:31] NOTICE[6532] chan_sip.c: Registration from ‘“2029” <sip:[email protected]:5060>’ failed for ‘10.50.1.98:5060’ - Wrong password

This is the extension that is permanently forwarded

That seems like a problem… No help, just saying it looks like a database error that’s going to come back by itself.

I’d be deleting this extension from the system and recreating it. After that, I’d brick the phone and start 2029 over again.

It occurs to me that 2029 is not registered, so all of it’s calls are going to go to the defined Follow Me destination. Check that and see if there’s anything hinky on that page. Note that deleting and recreating the extension should wipe any settings (like custom FMFM stuff) so that might be a belt-and-bracer solution.

Hi Dave,

We did delete the extension 2029 and the Unconditional Fwd appears to be inactive. Last thing before the tech left he deleted the extension and recreted it. I con’t know if he defaulted the phone and tried again to provision it.

Just to be clear, that is the sqlite3 astdb database trashed not anything mariadb. I would
from a shell

rasterisk -x 'database show'|grep -i CF

to look for CF’s (CallForward) of any variety, (it could also be set on the phone.)

1 Like

FreePBX 14.0.16.4
PBX Distro:12.7.8-2012-1.sng7
Asterisk Version:13.18.5
Same issue here
Extension #13 Call Forward Unavailable
Extension #21 Call Forward Busy
I will try “core restart” at days end to see if it clears it

@dicko
/CFB/21 : 15
/CFU/*8013 : *8010
/CFU/13 : 48

rasterisk -x 'database deltree CFB'
rasterisk -x 'database deltree CFU'

and for good luck

rasterisk -x 'database deltree CF'
1 Like

dicko
The phone has been defaulted and triple checked for an internal call fwd, none.

I’ll try those db commands, Thanks!

dicko that worked! Thanks!
@lgaetz Time for a bug report?

No, a corrupt astdb is usually caused by hardware failure.Better to check your memory and solidity of your power supply.

Edit: However in the past I have found that under certain race conditions even read access to astdb by not the asterisk process can cause lock problems, so perhaps Zulu ran into that too.

So although the CF status has been cleared from the database, the issue is ongoing
" rasterisk -x ‘database deltree CFU’
Database entries do not exist."

CFU (unavailable) is one ‘tree’ effecting call forward, CF (allways) and CFB (busy) also pertain.

I did all, that was just an example.
Also tried core restart after doing that, the problem is still there.
Any ideas where to go next?

No guessing allowed, post a log.

Problem solved. Apparently right after performing the steps someone sat at that desk and activated DND and the person onsite who was testing did not accurately report what happened when calling that extension.
Thanks for your assistance!

I ran the deltree commands and got no entries found. The tech is also having issues with getting the 2029 to register to the system. We keep getting “Wrong Password” Should we be looking at hardware?