[asterisk-bugs] [JIRA] (ASTERISK-16475) CDR user fields not updated and CDR() returns invalid data when using Queue with "c" flag

Matt Jordan (JIRA) noreply at issues.asterisk.org
Fri Mar 27 15:38:34 CDT 2015


    [ https://issues.asterisk.org/jira/browse/ASTERISK-16475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225668#comment-225668 ] 

Matt Jordan commented on ASTERISK-16475:
----------------------------------------

I'm going to go ahead and close this out as "Won't Fix."

First, Leif and Tilghman were absolutely right in their assessment of CDRs. "Thar be dragons in that thar code."

Second, we fundamentally changed CDRs in 12+. In some ways, the behaviour as described above is now, well, by design. You will get multiple records depending on what the call does, and they may have different durations. The assumption of CDRs is that once you hit a particular point of complexity, you are going to have to post-process your records. Asterisk is too complex and allows a user to do too many things to pretend like it can provide one consistent picture of the world. Sometimes the best it can do is present you with what happened, and let you go make a billing record out of it.

At any rate, we won't lose information in 12+.

> CDR user fields not updated and CDR() returns invalid data when using Queue with "c" flag
> -----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-16475
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16475
>             Project: Asterisk
>          Issue Type: Bug
>          Components: CDR/General
>            Reporter: Kirill Katsnelson
>            Severity: Minor
>
> When Queue() is called with the "c" flag (continue dialplan after agent hangup):
> # assignments made to CDR(...) values from the h extension are not written to the database; these are the userfield and all additional custom fields (used with  adaptive_odbc).
> # {{CDR()}} fields are reset to defaults. These are {{CDR(billsec)}}, {{CDR(duration)}}, {{CDR(disposition)}} -- possibly more.
> *STEPS TO REPRODUCE*
> {code}
> context cdr-bug {
>   777 => {
>     QUEFLAGS = "ct";
>     CDR(userfield)="before queue";
>     Verbose(1, Before Queue: QS:${QUEUESTATUS} T:${CDR(billsec)}/${CDR(duration)} D:${CDR(disposition)} A:${CDR(amaflags)});
>     Queue(QTest,${QUEFLAGS});
>     CDR(userfield)="after queue";
>     Verbose(1, After Queue: QS:${QUEUESTATUS} T:${CDR(billsec)}/${CDR(duration)} D:${CDR(disposition)} A:${CDR(amaflags)});
>   }
>   h => {
>     CDR(userfield)="hangup";
>     Verbose(1, Hangup: T:${CDR(billsec)}/${CDR(duration)} D:${CDR(disposition)} A:${CDR(amaflags)});
>   }
> }
> {code}
> Send a call to 777 at cdr-bug ("Customer" originates). Have a device in the queue QTest answer (this is the "Agent"). set core verbose 1 to see Verbose() output from the script.
> Test1: "Customer" hangs up 10 seconds into the call. 
>   Before Queue: QS: T:0/0 D:NO ANSWER A:DOCUMENTATION
>   Hangup: T:0/0 D:NO ANSWER A:DOCUMENTATION
> Values of 0/0 and "NO ANSWER" are wrong.
> CDR userfield set in the database to "before queue" -- expected "hangup".
> Test2: "Agent" hangs up 10 seconds into the call. The same problem.
> Agent hangup, CT
>   Before Queue: QS: T:0/0 D:NO ANSWER A:DOCUMENTATION
>   After Queue: QS:CONTINUE T:0/0 D:NO ANSWER A:DOCUMENTATION
>   Hangup: T:0/0 D:NO ANSWER A:DOCUMENTATION
> userfield: "before queue"
> Control. Change QUEFLAGS to "t" (remove the c flag), and the same 2 tests act normally.
> Customer hangup
>   Before Queue: QS: T:0/0 D:NO ANSWER A:DOCUMENTATION
>   Hangup: T:10/10 D:ANSWERED A:DOCUMENTATION
> Userfield:hangup
> Agent hangup
>   Before Queue: QS: T:0/0 D:NO ANSWER A:DOCUMENTATION
>   Hangup: T:8/8 D:ANSWERED A:DOCUMENTATION
> Userfield:hangup
> All values are present and database is updated with the correct value.
> *ADDITIONAL INFORMATION*
> I think that Dial() with the g flag has the same problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list