i’ve the problem, that after an upgrade to 2.4 the callerid isn’t set correctly in the config-files.
a call from device A to B always show “device A” instead of the real name of the extension.
i’d opend a ticket on freePBX.
they told me to check my astdb. but i don’t see any bugs.
i hope you can help me to find how to debug this.
in the meantime i’ve reprogrammed the php script “modules/core/functions.inc.php” to write
the field name instead of the description field in the database and config.
I remember this problem from long ago. First undo the change you made in the php script and set it to what it was (it works correctly when the database has the proper values). Then what you need to do is visit and edit each extension. To do that all you need to do is just submit at the bottom, don’t need to change anything. The issue is a value was not updated properly in one of the databases when you upgraded (don’t now why or which one off the top of my head) but when you click submit it fills in the database field with the correct info this time and things become good. Once you’ve done them all apply changes and reload and the problem will be gone.
if i save an extension, the database entry for a callerid is device and not the value i’ve entered.
it isn’t a problem with the astdb, you described above.
dwagner, the mysql database entry and sip_additional.conf entry are device and is suppose to be device. fskrotski is correct in that something corrupted or removed your astdb entries if you have been seeing device as your caller id. And you may have worse problems if you don’t address that vs. looking for what is wrong in the code when it is correct.
Every dialplan that is properly written in the system should call macro-user-callerid as its very first thing (or almost very first thing). This macro uses the device CID information to reset the Caller ID for the user who is logged into the device. In extension mode, you are always logged into the device.
The information is obtained by looking up the DEVICE/${CALLERID(number)}/user information to find out who the real user is, and then resetting the CallerID information, as well as setting other important channel variables (such as AMPUSER and others) that it gets out of the AMPUSER/user database object.
So you should focus on what you were suggested, get you astdb records built back up and/or find out what happened to corrupt them in the first place. Beyond that, if they are setup right and you are having issues, it would imply a bug in the dialplan that is not calling macro-user-callerid to sort all this out.