Upgraded from FreePBX 15 to 16 - now external call/CID forwarding stopped working?

[SSIRichard (Richard Loughran)]

Hello everyone. A few days ago I upgraded our FreePBX distro system from version 15 to 16 ( - no issues in that process at all. I also took the step of moving from Asterisk 16 to 18 (and have since switched back to 16 to reduce the number of changes involved)

The only thing that seems to have ‘broken’ is CID forwarding no longer works. Specifically, we have some users who use Find Me Follow Me enabled, and it will ring their deskphone and their personal cell phone. The behavior prior to the upgrade was their cell phone would ring, and it would show the caller ID of whatever external number was calling them.

Now, the calls never hit their cell phone. The only way I can get the calls to go through is if I force CID to a DID of ours either at the trunk level, or by setting the extension to a Fixed CID Value, but obviously this doesn’t pass along the original CID. Is there a change from 15 to 16 that would explain this?

Only other real change I made was I switched to using PJSIP for our trunk as that seems to be recommended. The issue with the CID forwarding occurred both the the SIP trunk and the PJSIP trunk. For now, I have set the trunk to Block Foreign CID’s so the call is at least forwarded properly.

[SSIRichard (Richard Loughran)]

Bizarre day for me. The only place where we have caller ID set is at the trunk level, and it was set to Allow Any CID (exceptions being for one outbound route for fax). All extensions just had that field blank. This has been true through FreePBX 14 and 15.

So the ‘fix’ seems to be that I filled in the CID field on my extension, and then tested calling it from an external number. Not only did the call come through to my cell, but it passed caller ID. I cleared the field again, and ran another test, and it still works. Furthermore, it seems that it’s working again for every extension. This is an issue I could replicate on-demand all week until I tried this today.

So I guess the question I’m left with, is it best practice to fill in the CID field for each extension? Does it make any sense whatsoever that what I did today would’ve fixed it?

[adell4444 (Andrew)]

There was an update that got pushed in core that broke caller IDs set at the trunk level. See this thread:

Change In Core for Outbound Caller ID

I did a batch of updates on my servers last night. I had a couple of customers advise me that their outbound calls weren’t working anymore, but inbound was fine. Tracing the problem back, Twilio was rejecting the call because the caller ID wasn’t a recognized number. It looks like the caller ID FROM is sending as the extension number now (sip:[email protected]). For these customers, the extensions do not have a classified CID. Following the chain of outbound calling, the outbound routes did n…

[SSIRichard (Richard Loughran)]

Ah interesting. So I just had unfortunate timing in the end. I wonder if my silly work-around would work for anyone else in the meanwhile.

[adell4444 (Andrew)]

Not silly, that is the workaround. Or setting the CID on an outbound route.

[SSIRichard (Richard Loughran)]

To clarify, the silly part (to me anyway) is the fact that I cleared the CID field on my extension and it still works. Nothing set on an outbound route, and the trunk has always had it. It was as if setting it once on a single extension fixed it for every extension, even after clearing it. Regardless, at this point I’m just happy it works and it’ll be even better when there’s an official fix out.

Thanks for pointing out that other thread by the way. I much prefer seeing a likely explanation for an issue as opposed to never really knowing.