[asterisk-bugs] [Asterisk 0015613]: Changes to CALLERID don't get propagated to CDR(clid)

[Asterisk Bug Tracker]

The following issue has been REOPENED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15613 
====================================================================== 
Reported By:                pyves
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15613
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-07-30 02:08 CDT
Last Modified:              2009-08-14 21:05 CDT
====================================================================== 
Summary:                    Changes to CALLERID don't get propagated to
CDR(clid)
Description: 
Whenever I make changes to CALLERID, using Set(CALLERID(num)=....) or
PrivacyManager() in the dialplan, the changes don't propagate to CDR(clid).
Whatever caller id was sent over by the SIP client (and I've tried many SIP
clients, soft and hard, to ensure there wasn't a client issue) sticks to
CDR(clid) and hence my cdr backends (and this occurs with both csv and
sqlite3) aren't reflecting the correct clid. This is obviously particularly
problematic while using PrivacyManager(), as you loose the information
being provided by the caller.

====================================================================== 

---------------------------------------------------------------------- 
 (0109069) pyves (reporter) - 2009-08-14 21:05
 https://issues.asterisk.org/view.php?id=15613#c109069 
---------------------------------------------------------------------- 
Indeed that seems to be the solution, if I explicitly Set(CALLERID(ani)=)
then subsequent changes to CALLERID(num) get reflected in the CDR.

That said, I still think there's an issue at hand.

My understanding is that ANI is a purely POTS/PSTN concept, hence the fact
that CALLERID(ani) is set by default for an incoming IAX2 or SIP client,
leading to unexpected behaviour's down to the road due to "ani" having
higher priority than "num" for CDR purposes (despite "num" being the
information passed downstream to further SIP or IAX2 clients), seems to be
a flaw.

Sure, if ANI was set by a DAHDI channel coming from PSTN or ISDN, that
would make sense I suppose. But I'm dealing with pure SIP and IAX2.

IAX2 seems to have some "sendani" option, which presumably disables
setting ANI if set to "no". But with SIP, I'm not seeing any such option.
There should be a global "dontsetani" or "ignoreani" or "cdrnoanipriority"
option (you get the idea) that's either set in asterisk.conf or in
[general] in extensions.conf. And I would argue that the default setting
for that option should be set to "yes" (but that's less relevant). I can't
seem to find any such option. As a result, I have to set CALLERID(ani) to
blank at multiple points in my dialplan in order to get what I consider is
the expected behaviour when dealing with channels that aren't directly
related to POTS/PSTN.

Am I missing something in my reasoning? Is there a global setting I
couldn't find? Is there a good reason CALLERID(ani) is set by default? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-14 21:05 pyves          Note Added: 0109069                          
2009-08-14 21:05 pyves          Status                   closed => new       
2009-08-14 21:05 pyves          Resolution               no change required =>
reopened
======================================================================