Use user extension as part of CID

I’ve searched for this everywhere, but all I get is either bare Asterisk solutions that won’t work with FreePBX (2.11), or solutions that only work for tiny installations due to the overhead involved…

Basically, this: I’ve got a call center working for several companies, and outbound routes which set the CID for the appropriate company hotline number according to a prefix dialled before the customer’s number. So far, so usual.
I now want to give our call center staff an opportunity to choose “let me dial out with who I really am”, e.g. for personal calls etc, where they appear to the called party with their real call-back-able number. I failed to achieve that so far. Theoretically, this would just require a Set(CALLERID(number)=004912345678${AMPUSER}); in the appropriate place in the dialplan.
I tried putting this into the Override CID field in FreePBX, but I get “Invalid outbound CID”, because the ${AMPUSER} part is non-numeric. I can’t put it into extensions_additional.conf where the outbound routes are defined, because this file gets rewritten after each configuration change. I don’t want to modify the FreePBX web configurator code to create this line, because that approach is plain ugly and gets destroyed with module updates.
Is there any non-ugly way to configure that?

Not sure, due to the old version, but could you use ${EXTEN} instead of ampuser? Another option I have not tried, but might work is to use ${CALLERID(num)} or ${CALLERIDNUM}, depending on the Asterisk version.

yeah, I know all my variables… it’s just that I don’t know where to configure that.
The FreePBX web interface doesn’t allow me to use variables in the CID field.
Editing it into the config files manually means it will get overwritten at the next Apply Config run.

Does the extensions_custom.conf and/or extensions_override.conf exist on your version of Asterisk?

Custom is where you build something custom, that doesn’t exist elsewhere in the dialplan.

Override is where you override something in the dialplan to change its behavior and not have it be overridden by the system on the next apply config.

yes. I knew about the _custom, and am using that extensively already. I did not know that there is an _override as well… I will look into that whether I can use that to modify the existing macro for that outbound route.

I don’t understand why you need to do anything custom at all. When you dial a special prefix, I assume that it matches an Outbound Route that has Route CID set with the hotline number of the corresponding company and the route has the Override Extension box checked.

When you dial without a special prefix, the ‘normal’ Outbound Route selected should not have Override Extension checked, so the value of Outbound CID for the extension making the call, for example “John Doe” <004912345678123> would be used and 004912345678123 would be sent out on the trunk (in the From, Remote-Party-ID or P-Asserted-Identity header, as required by your provider).

If the above won’t work on your system, please explain what goes wrong, or what additional constraints you have.

That’s what I originally thought as well… but if I don’t set any CID, Asterisk/FPBX only uses the three-digit device ID (not even the user’s extension) as outgoing CID, which the provider recognizes as invalid and thus discards / replaces with our main number. This would probably work if I had a separate fully-qualified CID defined for every device, but I don’t have that currently, and retroactively adding that to 500+ device configs is quite a chore.

Does Bulk Handler exist in your version or FreePBX? If it did, you could export all of your extensions, make the change really fast in the excel export, then import the changes. Should only take minutes.

Maybe “Bulk Extensions” if its an older version of FreePBX

1 Like

+1 on @comtech 's suggestion.

To be conservative:

  1. Back up your system.
  2. In the normal GUI, manually edit the Outbound CID for one extension and test that it works as expected.
  3. In Bulk Extensions, export the data, truncate it to header + one or two entries, change the outboundcid columns, import and test.
  4. If the above is successful, do the modification on the full exported extension list.

I’ve come one step further, but still no banana…
I’ve gone into the FreePBX config mysql database, and said
update users set outboundcid=CONCAT('<491234567', extension, '>') where extension like '5%'
(5xx are our internal extensions)
This populated the database correctly with the user’s outgoing CID.
Then I created an outbound route with a prefix that sends an unmodified CID.
This… works, kinda, but not completely.
When I call my mobile from my desk phone (internal ext# 555), it shows up on the mobile as call from +555
When I then go into FreePBX GUI, pull up my user account 555, hit save and apply (with no changes made) and call again, it shows up on the mobile correctly as call from +491234567555.
Sooo… simply saving the user info with the OutboundCID field being populated, seems to set a flag somewhere that is responsible for pulling the correct CID from the DB instead of using +Extension# but I have no idea where.
Does this ring a bell for someone here who could point me in the right direction?
I’m not much in favor of pulling up many hundred user accounts just to hit ‘Save’ on each one manually…

I think I’m on to something there… the Save and Apply also writes the outboundcid into the Asterisk internal database, not only the FreePBX config mysql.
Is there a way to populate the Asterisk DB in the same way as I did with the config mysql?

The asterisk database is /var/lib/asterisk/sastdb.sqlite3 and talked about here

Due to the imperfect locking used, either shutdown asterisk when working directly on the datadase, or use ‘wrappers’ around the asterisk ‘database put/add/get/query’ functions from bssh or just do it from the asterisk cli.

I just wrote a shell oneliner to generate all the “database query ‘update astdb’…” commands for me and threw that into the asterisk CLI at a quiet moment. Wasn’t pretty but worked fine.

1 Like

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