Skip to main content

Forward calls conf file?

Posted by ksupport on Mon, 06/07/2010

I set up my call forwarding and it is working. My question is where is that info being stored? I ran
find . -type f -print|xargs file|grep -i MyCellPhone# and was not able to find which file this is stored in.

I was looking in /etc/asterisk and using PBX Manager 6.0.1.81 and Asterisk 1.6.2.7


Submitted by eeman on Mon, 06/07/2010 Permalink

its stored in a berkleydb file called the ASTDB /var/lib/asterisk/astdb

asterisk -rx "database show" | grep MyCellPhone#

Submitted by ksupport on Tue, 06/08/2010 Permalink

I was just made aware of a problem with a users extension. When I call/dial 1650 it is being forwarded to an external #. I have checked the forward settings for extension 1650 and nothing is set to forward.

I ran the command and don't see the cell phone # listed. Where else should I look? How do I find why this external # is being called?

Submitted by eeman on Tue, 06/08/2010 Permalink

watch dialplan in the CLI... (best to capture late at night so you can see this happening)..

the phones themselves also have the ability to issue a 'Temporarily Moved' message (which shows up in the CLI capture).

so in your case you would see

SIP/1650 is ringing

111.111.111.111 sent Temoprarily moved message

then you would start seeing new dialplna for the forwarded #.

this can be even more elusive if instead of 'call forward always' being set on a phone, they set some 'call forward no answer' option after 4 rings.. because then sometimes it works and sometimes it forwards. I Had to chase a call-forward-no-answer problem down where the guy programmed an invalid extension.. every time we tested i could call his extension yet he insisted when someone transferred a call to his extension they kept getting a recoding of 'invalid'. Turns out it happened when he was out of the office and after 4 rings it was forwarded to an 8 digit phone number (not valid in the USA).

he didnt believe me... thank goodness they were polycom phones using FTP provisioning; because the phones upload a macaddr-phone.cfg file full of overrides INCLUDING the bogus # he set his call-forward-no-answer to. Smoking gun, but took a while to find out that 'invalid' wasnt an immediate responce, but rather 4 rings then 'invalid'. I just happened to call on a day he was out of the office.. we were convinced his receptionist was incapable of transferring a call consistently.