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 ?