[Home]

Summary:ASTERISK-14563: Changes to CALLERID don't get propagated to CDR(clid)
Reporter:Yves Perrenoud (pyves)Labels:
Date Opened:2009-07-30 02:08:35Date Closed:2011-06-07 14:07:58
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.
Comments:By: Tilghman Lesher (tilghman) 2009-07-30 09:10:30

The first thing I'd check is your Caller Presentation, as those values affect how CallerID is propagated to CDRs.  If the presentation is any part of "prohib" or "unavailable", that would be why the callerid isn't passed.
By: Yves Perrenoud (pyves) 2009-07-31 01:13:15

First of all, I forgot to mention this occurs with IAX2 as well, and if I'm not mistaken there isn't any caller presentation set of options with IAX2. In any case, I've checked my SIP caller presentation setting, and it's at the default of "allowed_not_screened".
By: saghul (saghul) 2009-08-04 05:20:27

I'm facing the same issue in Asterisk 1.4.24 If I do this it doesn't work:

Set(CALLERID(num)=1234)

But if I do this:

Set(CALLERID(all)="foo"<1234>)

it does work!
By: Yves Perrenoud (pyves) 2009-08-05 18:00:01

Indeed, it's also working for me when I use CALLERID(all). In fact it also works with CALLERID(name). So it's CALLERID(num) (ultimately the more useful of the three in my view) that's not working. I assume PrivacyManager() must be accessing CALLERID(num) under the hood as well, which is probably why it's also affected.
By: Tilghman Lesher (tilghman) 2009-08-06 17:21:04

No, what that tells me is that you have CALLERID(ani) set, as CDR prefers using CALLERID(ani) for its clid over CALLERID(num).  When you set CALLERID(all), it overrides CALLERID(ani) with the same value as the number.
By: Tilghman Lesher (tilghman) 2009-08-06 17:22:57

Update the ANI, if you want the information reflected in the CDR.
By: Yves Perrenoud (pyves) 2009-08-14 21:05:38

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?
By: Tilghman Lesher (tilghman) 2009-08-15 09:04:24

Those are all good questions for the asterisk-dev list, but due to the limited scope of this forum, is not an appropriate question on the issue tracker.  Please redirect your query to the asterisk-dev list.

To be clear, I'm fine with changing the code back to only setting CALLERID(num), but I cannot make such a change unilaterally, without discussion from other developers, because 1) ANI has been there for the entire 1.4 series, so backwards compatibility is a factor, and 2) there may have been a good reason to change it that I am not seeing.