[Home]

Summary:ASTERISK-07498: CLID and SRC fields incorrect in CDR table when setting CallerID from dialplan
Reporter:inspired (inspired)Labels:
Date Opened:2006-08-09 09:09:18Date Closed:2006-08-30 14:01:30
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hi,

I recently upgraded from 1.0.7 to 1.2.10 and noticed that the CLID and SRC fields in the 'cdr' table are incorrectly set for calls. For incoming calls from PRI CLID and SRC are correct, meaning they are set to the calling number, but when making an outbound call CLID and SRC are incorrect. This occurs when setting CALLERID(number) or CALLERID(name) from the dialplan. If I run a NoOp(${CALLERID(number)}) I get the correct caller ID, but when I take a look at the 'cdr' table the caller ID is set to the SIP Username making the call. However, if I do specify callerid='21651012' in my sip_users table, the caller id is correctly set in my cdr. See below. The NoOp is set to show ${CALLERID(number)}):
   -- Executing AGI("SIP/111110010-082448e8", "consoll/callerid.pl") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/consoll/callerid.pl
   -- AGI Script consoll/callerid.pl completed, returning 0
   -- Executing NoOp("SIP/111110010-082448e8", "21651012") in new stack
   -- Executing Dial("SIP/111110010-082448e8", "Zap/g1/99355151|60|gt") in new stack

The resulting cdr record for this call:
| uniqueid | userfield | accountcode | src       | dst      | dcontext             | clid                          | channel                         | dstchannel             | lastapp    | lastdata                  | calldate            | duration | billsec | disposition | amaflags |
+----------+-----------+-------------+-----------+----------+-------------------
|          |           |             | 111110010 | 99355151 | consoll              | 111110010                     | SIP/111110010-082448e8          | Zap/1-1                | Congestion |                           | 2006-08-09 15:57:57 |        1 |       0 | NO ANSWER   |        3 |


The two occurences of '111110010' in the cdr should in fact have been '21651012'. I tried using Set(CDR(clid)=${CALLERID(number)}) as an alternate fix but I got an error because clid is read-only. I believe there is a bug in Asterisk 1.2.10. With the exactly same setup on 1.0.7 clid and src would have been 21651012.
Comments:By: inspired (inspired) 2006-08-09 09:47:31

Sorry, title should be "CLID and SRC fields incorrectly set when using cdr_addons_mysql" !
By: inspired (inspired) 2006-08-10 02:32:51

I just verified that this not only happens when using cdr_addons_mysql, but also from a sip friend in sip.conf. If I set the callerid in sip.conf, it is reported correctly in the cdr table, but if I set it in the dialplan prior to calling, it is incorrectly set, even though I removed the callerid="21651012" <21651012" from the sip friend. I would suggest that this bug report should be updated with severity = major and title should be changed to: "CLID and SRC fields incorrect in CDR table when setting CallerID from dialplan"


By: Clod Patry (junky) 2006-08-11 11:20:16

i switch it to crash, since, without the patch, it crashes.
By: Serge Vecher (serge-v) 2006-08-11 11:39:14

inspired: if Asterisk crashes, then we need a backtrace. Make sure you build asterisk with 'make dont-optimize.' Review this page, if you don't know how to make a bt http://www.voip-info.org/tiki-index.php?page=Asterisk%20debugging
By: inspired (inspired) 2006-08-13 07:03:16

Hi vechers: Asterisk does not crash. The issue is that it is no longer possible to change CLID and SRC fields from the dialplan like it was possible with 1.0.x and earlier versions. Only the channel variables CALLERID(number) or (name) are set. And please also change the topic of this issue, since it is now misleading. I confirmed that this is not only a cdr_addons_mysql issue, but more of a general issue.

To junky: What patch? Is there one?
By: inspired (inspired) 2006-08-15 09:51:54

Tested with 1.2.5 as well. Same thing happens. However, on my development system I  noted that if I remove the contents of callerid from my friend in iax_friends (only tested iax) I can correctly set CALLERID from the dialplan. This is not correct behaviour though, since I can no longer manipulate the CALLER ID for a user with an existing CALLER ID like I could on 1.0.7.
By: Roy Sigurd Karlsbakk (rkarlsba) 2006-08-29 09:30:26

This was broken in

2006-07-03 05:12 +0000 [r36697-36751]  Russell Bryant <russell@digium.com>

revision 36725

Also note that this affects all sorts of CDR logging, and is not related to any database or similar.

roy


By: Roy Sigurd Karlsbakk (rkarlsba) 2006-08-29 09:39:18

It seems russel has changed the default behaviour here from using callerid(number) to using callerid(ANI) in the CDR logging, which is something I would call pretty damn ugly thing to do between 1.2.9 and 1.2.10
By: Serge Vecher (serge-v) 2006-08-29 09:40:23

ok, something doesn't jive here:
Inspired says the bug is present in 1.2.5
RoyK says the bug was caused by 36725. The release at the time was 1.2.9.1

Are you guys talking about two different bugs?
By: Roy Sigurd Karlsbakk (rkarlsba) 2006-08-29 09:46:18

no, inspired was messing up
I am positive this is where the bugs shows up
if trying to set CALLERID(ANI), the cdr log is correct
By: Serge Vecher (serge-v) 2006-08-29 10:46:47

rkarlsba: thanks for the clarification.

ok, then, aside from "broken expectations," I don't see that there is an actual bug here. If you guys need to see the "old" callerid(number) in the CDR logs, why not put them in one of the custome fields?
By: Roy Sigurd Karlsbakk (rkarlsba) 2006-08-29 11:25:55

As long as important, basic functionality changed in the feature-frozen 1.2 branch, this must be regarded as a bug. The docs I can find about callerid/cdr does not state anywhere that the ANI is used (checked the old handbook, the new book and voip-info). I would guess there are quite many people out there are relying on the 'old' way, so it's a bad, bad thing to cut support for this in the middle of a branch.

roy
By: Serge Vecher (serge-v) 2006-08-29 11:38:04

well since the change was made by an official maintainter of the release branch, the behavior change was the intended effect. The point about updating documentation is valid though, so the patches are welcome.
By: Roy Sigurd Karlsbakk (rkarlsba) 2006-08-29 12:12:10

How can you allow such a change in the release branch??? The branch is frozen, and new stuff are not meant to go in. That also includes new behaviour.

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2006-08-30 03:22:56

thanks to russel to allow this to change back in 1.2

roy
By: Russell Bryant (russell) 2006-08-30 14:01:29

This has been cleared up in the 1.2 branch in revision 41411.  Please see the following message to the asterisk-dev mailing list for further explanation on the issue here:

http://lists.digium.com/pipermail/asterisk-dev/2006-August/022674.html