[Home]

Summary:ASTERISK-18699: CDR record not updated when using func_callerid
Reporter:rsw686 (rsw686)Labels:
Date Opened:2011-10-10 09:39:48Date Closed:2011-12-20 08:57:14.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Functions/func_callerid
Versions:1.8.7.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.8.0-cdr-clid.patch
( 1) asterisk-1.8.0-cdr-clid2.patch
Description:When setting the caller id with CALLERID(number) or CALLERID(all) the CDR clid field is not updated. The General section Caller ID is correct, but the CDR Variable clid is not. This worked previously in 1.6.1.18.

core show channel SIP/1050-00000004
-- General --
          Name: SIP/1050-00000004
          Type: SIP
      UniqueID: 1318256404.4
      LinkedID: 1318256404.4
     Caller ID: 7031234567
Caller ID Name: (N/A)
Connected Line ID: (N/A)
Connected Line ID Name: (N/A)
   DNID Digits: 7039361212
      Language: en
         State: Ring (4)
         Rings: 0
 NativeFormats: 0x4 (ulaw)
   WriteFormat: 0x4 (ulaw)
    ReadFormat: 0x4 (ulaw)
WriteTranscode: No
 ReadTranscode: No
1st File Descriptor: 28
     Frames in: 30
    Frames out: 30
Time to Hangup: 0
  Elapsed Time: 0h0m4s
 Direct Bridge: <none>
Indirect Bridge: <none>
--   PBX   --
       Context: macro-dialout-trunk
     Extension: s
      Priority: 19
    Call Group: 0
  Pickup Group: 0
   Application: Dial
          Data: SIP/gafachi1a/17039361212,300,TW
   Blocking in: ast_waitfor_nandfds
     Variables:
DIALEDTIME=
ANSWEREDTIME=
DIALEDPEERNAME=
DIALEDPEERNUMBER=
DIALSTATUS=
MACRO_DEPTH=1
MACRO_PRIORITY=4
MACRO_CONTEXT=from-internal
MACRO_EXTEN=7039361212
ARG1=6
custom=SIP/gafachi1a
OUTNUM=17039361212
AGISTATUS=SUCCESS
DIAL_NUMBER=17039361212
TRUNKOUTCID=
EMERGENCYCID=
USEROUTCID=7031234567
DB_RESULT=7031234567
DIAL_TRUNK_OPTIONS=TW
OUTBOUND_GROUP=OUT_6
DIAL_TRUNK=6
ARG4=
ARG3=
ARG2=7039361212
NODEST=
AMPUSERCID=2001
AMPUSERCIDNAME=
AMPUSER=2001
REALCALLERIDNUM=1050
SIPCALLID=3fa296e1-6a9e9830-12b75aeb@10.10.1.149
SIPDOMAIN=voip.domain.net:5060
SIPURI=sip:1050@10.10.1.149:51460

 CDR Variables:
level 1: dnid=7039361212
level 1: clid=1050
level 1: src=1050
level 1: dst=7039361212
level 1: dcontext=from-internal
level 1: channel=SIP/1050-00000004
level 1: dstchannel=SIP/gafachi1a-00000005
level 1: lastapp=Dial
level 1: lastdata=SIP/gafachi1a/17039361212,300,TW
level 1: start=2011-10-10 10:20:04
level 1: duration=3
level 1: billsec=0
level 1: disposition=NO ANSWER
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1318256404.4
level 1: linkedid=1318256404.4
level 1: sequence=4
Comments:By: rsw686 (rsw686) 2011-10-10 10:33:05.739-0500

I've tracked this down to the set_one_cid function in main/cdr.c. When calling CALLERID() the caller.ani is checked first so caller.id is not used to update the cdr. Switching these resolves the issue and brings back the previous behavior of 1.6.1.18.
By: Leif Madsen (lmadsen) 2011-10-31 15:13:31.679-0500

Honestly I'm not sure we want to implement this at all. CDR's are one of those things where we play the whack-a-mole game. By making changes to the CDR code, we inadvertently hit one mole, and another pops up somewhere else.

I personally would prefer changes to CDR be frozen and that changes be made only locally.
By: rsw686 (rsw686) 2011-10-31 23:12:48.700-0500

{code} /* Grab source from ANI or normal Caller*ID */
num = S_COR(c->caller.ani.number.valid, c->caller.ani.number.str,
S_COR(c->caller.id.number.valid, c->caller.id.number.str, NULL));
ast_callerid_merge(cdr->clid, sizeof(cdr->clid),
S_COR(c->caller.id.name.valid, c->caller.id.name.str, NULL), num, "");
ast_copy_string(cdr->src, S_OR(num, ""), sizeof(cdr->src));{code}

As the code currently reads you get the name set by caller id and the number from ANI then caller id only if the ANI isn't valid. Why would I want a the name from caller id and the number from ANI if I had set the caller id number?

The best solution would be to set clid to the caller id name and number and leave src set to the ANI and only use the caller id number if the ANI isn't valid. This would provide a combination of both the 1.6.1 and 1.8 behaviors.

To give you some background I am using FreePBX in user and device mode. When a call is placed the user for the device is looked up and CALLERID() is called. With 1.6.1 it was straight forward to parse the CDR records and know which user the call came from. With 1.8 I now have to perform a lookup to determine the user for the device in the CDR record. If I happen to reassign a device to a different user the lookup will not work as expected.
By: rsw686 (rsw686) 2011-11-01 09:16:49.911-0500

I've added a revised patch which implements the behavior described in the previous comment.
By: Matthew Nicholson (mnicholson) 2011-11-11 16:07:40.912-0600

The problem does not appear to be changes made in set_one_cid(). It seems to have favored ANI to callerid number for quite some time. Your patch would probably have unforeseen repercussions for people who depend on this behavior.

Please post two examples, one from asterisk 1.6.1.18 and one from the latest 1.8 version demonstrating this regression. Post the resulting cdr record from each version and the dialplan used to generate it.

If my analysis of the code is correct, you should be able to work around this issue by setting CALLERID(ani) instead of CALLERID(number) or CALLERID(name).
By: rsw686 (rsw686) 2011-11-12 10:11:48.327-0600

I see what you are saying with set_one_cid() being basically the same. The production box experiencing this problem was running Asterisk 1.6.1.18 with FreePBX 2.7. I only upgraded Asterisk to 1.8.7.0 and experienced the CDR issue. Now it could be that Asterisk 1.6.1.18 didn't set the cid_ani so cid_num was used. I will have to setup a different box to test this.
By: Matthew Nicholson (mnicholson) 2011-11-30 15:23:18.860-0600

Any updates on this?
By: Leif Madsen (lmadsen) 2011-12-20 08:57:02.401-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines


By: Jamuel Starkey (jamuel) 2012-01-17 01:02:55.419-0600

Matthew's assertion is correct--setting CALLERID(ani) correctly setts the CNUM and src fields in CDR. I stumbled across this issue when using FreePBX and moving from 1.6.2.20 to 1.8.9.0-rc1.  Adding CALLERID(ani) is an easy enough patch to FreePBX rather than whacking the mole in cdr.c

:)

By: JoshE (n8ideas) 2012-04-10 10:40:21.089-0500

Just a note that this affects Asterisk 10.3.0 as well.  The work around is setting CALLERID(ANI-num), but this is hardly intuitive.

I'm no fan of whack-a-mole either, but this isn't quite intuitive behavior, nor is documentation easily available.