[Home]

Summary:ASTERISK-11243: CALLERID is not logged correctly into cdrs
Reporter:Loic Didelot (voipgate)Labels:
Date Opened:2008-01-15 14:53:19.000-0600Date Closed:2008-02-26 12:12:14.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I can set my callerid using the CALLERID function and this works great on the dialplan. I can read and write to it,the callerid is applied, but inside the cdr records it is the first callerid that has been provided and not the one that i defined.


If I modify my CALLERID it should be logged to the cdr table.
Comments:By: Jason Parker (jparker) 2008-01-15 15:20:06.000-0600

Can you give an example of usage?  Are you using Set(CALLERID(num)=12345) or Set(CALLERID=12345) ?
By: Tilghman Lesher (tilghman) 2008-01-15 16:11:36.000-0600

Are you talking about the callerid field or the src field?  The src field documents the ANI, not the CID (but falls back to CID if ANI is not set).
By: Loic Didelot (voipgate) 2008-01-16 02:32:13.000-0600

I use Set(CALLERID(num)=12345) and Set(CALLERID(name)="MY TEST NAME").  In the database I talk about the clid field but I just checked and the src field is wrong too.
By: Alisher (licedey) 2008-01-19 11:09:11.000-0600

clid and src fields in CDR() are also read only. If we could edit them, it would be possible to correct the callerid from dial plan.


By: Tilghman Lesher (tilghman) 2008-01-20 21:26:14.000-0600

Wow, editing CDR fields?  That would be such a great idea.  Especially when you consider that your changes would be immediately overwritten the next time the CDR is updated.
By: Tilghman Lesher (tilghman) 2008-01-20 21:36:30.000-0600

voipgate:  at what point in the call are you modifying the CallerID?  If you are doing so in the 'h' extension, especially if you're using the setting endbeforehexten=yes in cdr.conf, that would explain why you'd be unable to change the CallerID (because it would have already been posted to the database at that point).

Also, if you're using ForkCDR, the CDRs created prior to the ForkCDR call will have their CallerID unchanged (because they are locked at that point).
By: Loic Didelot (voipgate) 2008-01-22 08:12:32.000-0600

I modify my callerid before the 'h' even before the DIAL command.
By: Tilghman Lesher (tilghman) 2008-01-22 09:42:34.000-0600

Okay, then, since we're getting nowhere, please upload the contents of your extensions.conf.
By: Loic Didelot (voipgate) 2008-01-22 09:52:34.000-0600

I guess the field in CDR's is just read-only.

I can not upload my extensions.conf as my dialplan is far too complex (agi etc...).

See it like this:
- user establishes SIP call
- of course a callerid is set by the users device/software
- this callerid is saved in the cdr's
- of course i can not accept the users callerid and I reformat it to be conform with my carriers, security policies etc...
- the modified callerid is applied correctly to the call


The question is the following:
Should the function CALLERID modify the values in the cdrs. If not, then its not a bug and it is working as designed, even though I think that it should work differently.
By: Alisher (licedey) 2008-01-22 10:00:24.000-0600

Corydon76: in the cdr.conf I didn't have "endbeforehexten" option set. Isn't it set to "no" by default? I will try to add endbeforehexten=no to cdr.conf, but I think it will not work, since I tried to modify the callerid before h or even before the dial application was executed.

I use a work around to correct the caller id. instead of changing cdr(clid) in the dial plan I modify the cdr(userfield),which I don't use, the cdr is stored into the cdr_pgsql. I added a trigger to my postgres database, when userfield has value, it corrects the clid and src fields.
By: Tilghman Lesher (tilghman) 2008-02-12 23:57:14.000-0600

I still would like to see your extensions.conf.
By: Alisher (licedey) 2008-02-13 00:09:08.000-0600

[from-pstn]
exten=>s,1,SET(CALLERID(num)=0${CALLERID(num)})
exten=>s,2,SET(CDR(userfield)=${CALLERID(num)})
exten=>s,3,Dial(SIP/2000)
exten=>s,4,Hangup

I use PRI E1 line, the incomming CID numbers come from telco without leading 0, so I have to add 0 manually from dial plan.


By: Tilghman Lesher (tilghman) 2008-02-13 00:45:21.000-0600

Ah, I think I know what the problem is.  Try adding a Sleep(1) before the first step in your dialplan.  The key is that this is a PRI circuit, and the callerid sometimes arrives in a duplicate message, AFTER the initial setup message (in the duplicate message, the calleridname is also set).  You may notice that you'll suddenly start receiving calleridname on the SIP phone when you do this.

For the record, what I suspect is happening is that you are indeed setting it correctly in the CDR, and then it's getting RESET back to the original value when the duplicate message comes in over the PRI circuit.  You think that the second value is not having an effect on the CDR -- but it does; it's just getting set one more time by the PRI.
By: Alisher (licedey) 2008-02-13 00:59:42.000-0600

Sleep(1), Do you mean Wait(1) ? I will modify the dial plan as following,after testing I will tell you if it solved the problem:

[from-pstn]
exten=>s,1,Wait(1)
exten=>s,2,SET(CALLERID(num)=0${CALLERID(num)})
exten=>s,3,Dial(SIP/2000)
exten=>s,4,Hangup
By: Tilghman Lesher (tilghman) 2008-02-13 01:15:26.000-0600

Yes, Wait(1).  It's late, and I'm half thinking of going to sleep.  ;-)
By: jmls (jmls) 2008-02-17 13:12:46.000-0600

licedey - did it work ?
By: Alisher (licedey) 2008-02-18 03:41:17.000-0600

Sorry for late response. I took a test, Wait(1) didn't help. I even tried Wait(5) also same, nothing changed. I guess, there are should be some other way.
By: jmls (jmls) 2008-02-18 03:45:58.000-0600

Corydon76, back over the net to you ...
By: Alisher (licedey) 2008-02-18 04:53:11.000-0600

I contacted with telco, they told me that their equipment was designed the way it sends CID without leading 0. They cannot change it, they told me that I have to setup the pbx so it can adjust the CID.
By: Tilghman Lesher (tilghman) 2008-02-18 08:17:00.000-0600

jmls:  can you reproduce?  The problem is that his situation is unique and we cannot reproduce the problem, and unless we can reproduce the problem, we cannot come up with a fix.
By: jmls (jmls) 2008-02-18 08:25:09.000-0600

voipgate, what are you using for the cdr ? Database ? Postgresq ? MySql ? Odbc ? or are you using the .csv files

Have you checked the master.csv for the detail ?
By: Alisher (licedey) 2008-02-18 20:40:13.000-0600

As I mentioned above, I use Postgres(cdr_pgsql), I checked the master.csv the CID were not changed. I think my case is not unique. There were many sites where I had to fix the CID.
 -  When Asterisk box is connected to Legacy PBX and dialed numbers start with _9.
          exten=>_9X.,Dial(Zap/g1,${Exten:1})

In this case, how should I do if I want to save number without leading 9 ?

Some numbers from telco come with leading local area code, where for outbound calls we don't dial the area code. So, there should be a way to adjust cdr to show all numbers in same way, either with local area code or without.

Until now, I was doing it by patching the source code (directly in cdr_pgsql.c) or adding triggers to database. But this was not a good way, it would be easier if we could do it from dial plan.
By: Tilghman Lesher (tilghman) 2008-02-25 17:45:36.000-0600

I still think the issue is that your telco is sending the callerid number multiple times, each time of which it sets the callerid.
By: jmls (jmls) 2008-02-26 04:59:25.000-0600

afraid that I cannot reproduce this
By: Tilghman Lesher (tilghman) 2008-02-26 12:12:13.000-0600

Please open a ticket with your telco and ask them to only send CALLERID once.
By: Csaba Lack (csabka) 2011-07-13 21:16:45.276-0500

I think I have run into the same issue with Asterisk 1.8.4.2....

I have a static callerid field in sip.conf. When I overwrite with CALLERID(name) and CALLERID(number) /or CALLERID(all)/ in extensions.conf by dialplan... the CDR(src) remains as the sip.conf's callerid=<src>...  only the CDR(clid) name field can be changed with CALLERID(name) function.

eg:

[7141]
disallow=all
secret=*****
dtmfmode=rfc2833
canreinvite=no  
context=phone
host=dynamic
type=friend
nat=yes
port=5060
qualify=yes
allow=alaw  
dial=SIP/7141
callerid=test phone <7141>
callcounter=yes

in extensions.conf

[phone]
exten => _.,1,NoOp(phone1: cid: ${CALLERID(all)} exten: ${EXTEN} chan: ${CHANNEL} uniqeid: ${UNIQUEID} CDR(clid): ${CDR(clid)} CDR(src): ${CDR(src)} )
exten => _.,n,Set(CALLERID(all)="Test user <60001>")
;or: with same result
;exten => _.,n,Set(CALLERID(name)=Test user2)
;exten => _.,n,Set(CALLERID(number)=60001)

exten => _.,n,NoOp(phone2: cid: ${CALLERID(all)} exten: ${EXTEN} chan: ${CHANNEL} uniqeid: ${UNIQUEID} CDR(clid): ${CDR(clid)} CDR(src): ${CDR(src)} )
exten => _.,n,Dial(SIP/Trunk/06*****)
exten => _.,104,Macro(hangupcall,)

in this case...

Noop phone1:   -- Executing [06****@phone:1] NoOp("SIP/7141-00000022", "phone1: cid: "test phone" <7141> exten: 06**** chan: SIP/7141-00000022 uniqeid: 1310607460.44 CDR(clid): "test phone" <7141> CDR(src): 7141 ") in new stack

Noop phone2:   -- Executing [06****@phone:3] NoOp("SIP/7141-00000022", "phone2: cid: "Test user" <60001> exten: 06**** chan: SIP/7141-00000022 uniqeid: 1310607460.44 CDR(clid): "Test user" <7141> CDR(src): 7141 ") in new stack


In NooP phone2 the CDR(src) value should be 60001 and the clid should be "Test user" <60001>...

In SQL CDR the same bad values are there... after changing the sip.conf -> callerid=<othernum>, then everywhere 7141 replaced whith othernum (except the SIP/7141-0000 because the phone, registration is the same).


By: Olaf Winkler (abw1oim) 2011-07-14 00:57:40.316-0500

As Tilghman Lasher already wrote on 15/Jan/08 4:11 PM (!) You're problem should disappear if You insert one line in Your dialplan (before or after setting the CALLERID(all) or CALLERID(num) respecively and of course before You place Your dial-command):

exten => _.,n,Set(CALLERID(ani)=)

"The src field documents the ANI, not the CID (but falls back to CID if ANI is not set)"

It's not a bug, it's just a feature which needs to be understood to get the expected results ...