Is anyone else here dealing with Twilio disabling their Transit-Caller-ID feature on their SIP Trunk product recently (as of 10/20/2025), which is now the cause of any calls that were forwarded out of their FreePBX system with the original caller ID in place being blocked?
We reached out to support for clarification and according to them adding a diversion header should allow us to get these calls through but I am having a hell of time getting it configured properly.
I found some previous posts on adding the following to extensions_customs.conf:
I’ve also enabled the option “Generate Diversion Headers” in Advanced Settings.
Neither of those made a difference and calls forwarded out that contain an original Caller ID to a number that is not owned in Twilio are still getting blocked.
Anyone else here get this working for their system?
Also, SIPAddHeader only works with chan_sip. There is a FreePBX subroutine that handles this for both chan_sip and chan_pjsip, but I’d have to do some searching, for the details.
As your redaction isn’t clear, the Diversion URI will be the incoming “DID” URI.
I’ve never understood why a Diversion header should give the provider any confidence that this is a forwarded call; I would have thought the only way would be to forward the original stir/shaken information. However lots of people mention having to use them.
Talking to Twilio support right now but it looks like they are disabling the ability to show the original Caller ID on any forwarded call. Sounds like they will only allow numbers that you own in the affected account to be shown as an outbound caller ID.
If that is truly the case what’s the configuration in FreePBX to not pass the caller ID of a forwarded or transferred call as the outbound caller ID? I don’t recall ever needing to make a change to the settings to have forwarded calls show the Caller ID of the original caller.
This feels like a pretty big deal actually and I’ll follow up with anything else that I can find out from Twilio support.
As I understand it, the alternative is to send a B attestation, and they may have concluded that people are treating calls with B attestations as probable phone spam or vishing, and only accepting A attestations. My understanding is that A attestations can only be given if the caller ID has been proved to be controlled by the provider’s customer.
Determines what CIDs will be allowed out this trunk. IMPORTANT: EMERGENCY CIDs defined on an extension/device will ALWAYS be used if this trunk is part of an EMERGENCY Route regardless of these settings.
Allow Any CID: all CIDs including foreign CIDS from forwarded external calls will be transmitted. Block Foreign CIDs: Sets any CID that is the result of a forwarded call from off the system to the Outbound CallerID defined for the trunk. If no Outbound CallerID is defined for the trunk, the Foreign CID will be sent unchanged. CIDs defined for extensions/users are transmitted. Remove CNAM: this will remove CNAM from any CID sent out this trunk Force Trunk CID: Always use the CID defined for this trunk except if part of any EMERGENCY Route with an EMERGENCY CID defined for the extension/device. Intra-Company Routes will always trasmit an extension’s internal number and name.
Because I’ve never used the Trunk CID and always defined the CID in the Outbound Route because we tend to use multiple outbound routes with the same trunk, which takes precedence? The CID set in the Outbound Route or the CID set on the trunk?
It would suck if the Outbound Route CID would get overwritten on every other outbound call by the hard set Trunk CID.
Let’s make sure everyone has an understanding of this from the Asterisk and provider point of view. Asterisk is a Back2Back User Agent meaning the Call Forwarding or Follow-Me in FreePBX isn’t true forwarding. It’s creating a new channel and as far as the provider is concerned, this a new outbound call with no relationship to an inbound call with a CallerID they don’t allow.
Conversely, a Diversion will send back a 302 telling the provider that this incoming call is being diverted to a new destination and the provider is the one doing the forwarding. This is the true forwarding because it happens on the incoming channel from the provider. Therefore the provider knows this is a forwarded incoming call instead of it looking like a new call being made.
I think you mean a true, pre-answer, blind transfer.
Although, strictly speaking, Diversion, on a tandem call, is only defined for proxies, the impression I get, from postings here, is that some providers are allowing back to back user agents, to relay a call, with its original caller ID, as long as the outbound leg’s INVITE has a Diversion header.
For a pre-answer transfer, Asterisk doesn’t allow you to explicitly add headers, although it should be able to add Diversion where the appropriate. I’m not sure if the combination of post answer blind transfer (SIP REFER) and Diversion headers is actually specified anywhere, and, whilst Asterisk certainly won’t allow manual headers, I’m not sure there any automation, either.
Yea this would be a post-answer transfer/relay. We’d always want to process the call before forwarding it back out as that only happens in specific use cases like forwarding a call to an external voicemail service or simply forwarding a call from your extension to a cell phone.
