[Home]

Summary:ASTERISK-12924: After upgrading to 1.4.22 from 1.4.21.1 CDRs behave wrongly
Reporter:Holger (hesser)Labels:
Date Opened:2008-10-17 09:31:01Date Closed:2011-06-07 14:03:14
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:After the upgrade I am no longer able to set userfield nor accountcode variables in the CDR for my SQL backend. CSV does not work either. Also, there are no 2 identical call records in the database, whereas before, there were 2 individual records.
I am using the external interface to create a call from the from-internal context. Once the call is answered, it passes it to a context in extensions conf.
In there I am using exten => queue1,2,Set(CDR(accountcode)= "1234").
That used to set the record properly. It no longer does. I looked at the cdr.c in main and there are changes in regards to locked records, etc. I think that is where the issue comes from. Why were these changes implemented?

Kind regards
Holger
Comments:By: Leif Madsen (lmadsen) 2008-10-17 15:02:00

murf, I've assigned this to you as it is most likely that you will know how to approach this. Please re-assign if necessary. Thanks!
By: Steve Murphy (murf) 2008-10-24 15:49:48

I need to know more. If you are using call files to initiate the transfer, I need to see the contents of that call file. If you are initiating the call via the manager interface with Originate or something, the exact command used is what I need.

I need to see the dialplan involved in making the call.

I need to know what kind of phones are involved. Sip? Dahdi?

It looks like app_queue is involved? Show me the dialplan.
By: Leif Madsen (lmadsen) 2008-10-24 16:03:30

Thanks for the update Murf. I will try to remember those things for next time I see a CDR issue so I can request them immediately.
By: Holger (hesser) 2008-10-27 15:13:52

Hi Murf.
here are your answers ( I hope ).
Here is the manager interface call.
$TelnetClient->print ("Action: Originate");
   $TelnetClient->print ("Channel: $final");
   $TelnetClient->print ("Context: from-trunk-customer");
   $TelnetClient->print ("Priority: 1");
   $TelnetClient->print ("Exten: $dest");
   $TelnetClient->print ("Callerid: \"Intervoice\" <xxxxxxxxx>");
   
There is no queue app involved. ( just bad naming)
It fails for both SIP and IAX2.

The dialplan is the standart one coming from amportal.
By just changing out the versions of asterisk I can make it fail.

Let me know if you need a full log.

Thanks
Holger
By: Steve Murphy (murf) 2008-12-01 17:07:35.000-0600

Playing with the current 1.4 svn head, I created a fixed manager script:

Action: Originate
Channel: Dahdi/1
Exten: 8786
Context: extension
Priority: 1
Timeout: 10000
CallerID: d1a
Account: ManPlacedCall


for extension,8786 I have:

 '8786' =>         1. Set(CDR(accountcode)=1x334tq2z)            [pbx_ael]
                   2. set(CDR(userfield)=userfield1)             [pbx_ael]
                   3. Dial(Dahdi/2|10|tTwWkK)                    [pbx_ael]                                                                                                                              


and my CDR looks like:

""d1a" <101>","101","8786","extension","DAHDI/1-1","DAHDI/2-1","Dial","Dahdi/2|10|tTwWkK","2008-12-01 15:40:21","2008-12-01 15:40:24","2008-12-01 15:40:27","6","3","ANSWERED","DOCUMENTATION","1x334tq2z","1228171221.15","userfield1",""

(If I don't set the accountcode in the dialplan, then the set in the Originate command is not overridden, and the accountcode is set to ManPlacedCall.

So, this looks good to me. Please verify that the current SVN works correctly, and if not, please help me reproduce your problems.
By: Tilghman Lesher (tilghman) 2009-02-26 12:24:03.000-0600

No response from reporter.