Rerouted inbound call to external destination does not preserve CID

[osadmin]

What settings are needed exactly to preserve the caller id when a call is redirected to an external destination? Currently working in a FreePBX 15.0.16.78 install and both a misc destination and a ring group give the trunks outbound caller id instead of the original caller id. The trunks CID options are set to ‘Allow any CID’. (Have been searching about this topic before and I know this already > https://www.osadmin.be/about/freepbx-yealink-configuration/misc-destinations-and-how-to-preserve-cid-and-fix-sound/ but in this install, I can’t seem to get it to work in the first place.)

[lgaetz (Lorne Gaetz)]

If you look in the CDR for the outbound call, the Outbound CallerID column shows the CID string being sent to the provider from the PBX. If that value is correct, and the call still arrives with the wrong CID, then you need to raise the issue with your provider. It’s possible they don’t support the feature, or there is additional PBX config needed.

[sorvani (Jared Busch)]

@osadmin

The trunks CID options

What about your outbound route options?

[osadmin]

Outbound CallerID is correct in the CDR. I will raise the issue with the provider. Thank you!

[osadmin]

I have no ‘Route CID’ set in the outbound route.

[osadmin]

I was not exactly correct in describing my issue … it’s not the trunk’s outbound caller id that is shown but ‘private number’.
I’m also wondering what the difference is between these scenario’s …

Extension with different CID than trunk, calls mobile number => cell phone shows extension’s CID instead of trunk’s CID. = OK
Incoming external call to inbound route to misc destination that calls mobile number => cell phone shows ‘private number’.

[Stewart1 (Stewart)]

@osadmin

Extension with different CID than trunk, calls mobile number => cell phone shows extension’s CID instead of trunk’s CID as expected.

Even when (as a test) you temporarily set Outbound CID for the extension to the original caller ID that was failing?

When the call is not redirected, does the inbound CID show on the extension in the exact same format you are using for Outbound CID?

[osadmin]

@Stewart1

Even when (as a test) you temporarily set Outbound CID for the extension to the original caller ID that was failing?

Not sure what you mean by ‘the original caller ID that was failing’? (Extension with different CID than trunk that calls mobile number results in expected behaviour. The correct CID is shown on the cell phone.)

@Stewart1

When the call is not redirected, does the inbound CID show on the extension in the exact same format you are using for Outbound CID?

No …
Incoming external call to inbound route to extension => CID = 047xxxxxxx.
When I set the Outbound CID of my extension it’s format was <003214xxxxxx> with the country prefix.

[Stewart1 (Stewart)]

If (as a test) you temporarily set the Outbound CID for your extension to e.g.
"John Doe" <003247xxxxxxx>
and call a different mobile, does the caller ID show correctly on the destination phone?

If not, then you need to find out what your provider requires to send a number that’s not yours. It may be technical e.g. Diversion header, contractual (sign supplementary agreement) or they may not support it at all.

If the test with 003247xxxxxxx works ok, you need a hook to rewrite the 047xxxxxxx to 003247xxxxxxx before it’s sent to the trunk. See

Hooking for fun and income

Despite the frequency with which it arises here in the forum, there is not yet a good resource for learning to use dialplan hooks in FreePBX. This will probably end up in the wiki at some point, but until that happens, here are the broad strokes for leveraging dialplan hooks in FreePBX 14. What is a dialplan hook? A dialplan hook refers to several pre-defined FreePBX contexts that exist solely for users to add their own Asterisk Macros to be run at specific locations in the call flow. They all …

[osadmin]

@Stewart1

If not, then you need to find out what your provider requires to send a number that’s not yours. It may be technical e.g. Diversion header, contractual (sign supplementary agreement) or they may not support it at all.

This is the outcome! Thanks a lot for your help.

[osadmin]

So, to summarize for other readers, always test the behaviour of an extension CID (Outbound CID for your extension) you own and a random one, you don’t own!

[osadmin]

To complete this thread … I contacted my SIP provider and we have to provide them with the phone numbers that need this feature (proving we also own these phone numbers with invoices) and they will process our ‘clip no screening’ request.