RESOLVED-Outbound CallerID suddenly being set to Extension

Within the past week or two, with no known changes on our side, we have started receiving reports that outbound calls were being sent with the CID == the users extension across our primary sip trunk.

it IS possible that modules have been updated recently.

from troubleshooting and diagnosing, it appears the be triggering in macro-outbound-callerid on this line:
exten => s,n,ExecIf($[${LEN(${USEROUTCID})} = 0 & "${OUTKEEPCID_${ARG1}}" ="off" & ${LEN(${REALCALLERIDNUM})} != 0 ]?Set(CALLERID(all)=${REALCALLERIDNUM}))

more specifically that the OUTKEEPCID_3 (trunk 3) is set to Off, which is forcing caller id to be the realcallerID number.

as confirmed by adding in a logging NoOp:
$[${LEN(${USEROUTCID})} = 0 – user has no out CID, so always true
“${OUTKEEPCID_${ARG1}}” =“off” – this IS off. so this is always true for this trunk
${LEN(${REALCALLERIDNUM})} is not 0, thats their extension. so always TRUE

a few notes

  • we cant Force a callerID on this trunk, as it allows us to use multiple caller IDs across the same trunk

  • users do not have an assigned outbound CID

  • the outbound route IS set to override extension: YES

  • the outbound route HAS a routeCID.

    • so the ROUTE should be setting CID properly.
  • the Trunk has “Hide CallerID: NO”

  • the trunk has an outbound CID
    the trunk has CID Options set to “Allow Any CID”

This was all working fine for the past year or more, so I do not understand what would have changed in the past week to break this.

our current workaround is to comment out the above-listed line and asterisk -r + core reload, however our changed get overwritten every time an apply-config is performed.

I suppose the base question is: if my Outbound Route is set to have, and use, a route callerID, why is that no longer being honored at the trunk level in macro-outbound-callerid ?

Pretty sure its this:

the update to Core changing out all of the functions that handle outbound CID.

the linked module was actually a FIX for this issue, likely introduced relatively recently.

hitting Apply Config on of the CORE module now successfully resolves this issue.

Are you using edge track modules?
I believe the only version of core that had this was never released except in edge

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