[asterisk-bugs] [JIRA] Commented: (ASTERISK-20151) No CDR when queue call hangs up while ringing agent and 2 or more agents in that queue are busy

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-20151:
----------------------------------------

Backing this up a second.

"I can recreate the problem in Asterisk 10.6.1 by creating a queue called 'test', adding 3 queue members through AddQueueMember, making 2 of them busy by calling an outside line or calling each other, then putting a call in the queue. The queue will ring the free agent. While it is ringing, before the agent answers, the queue caller hangs up.
At this point a CDR should be created for this call in all configured cdr back ends, but none is created either in the CSV file, the pgsql database or throguh odbc to pgsql."

This is incorrect.  If a queue caller hangs up before anyone is answered, then a CDR record is only created if the unanswered=yes option is present.  In that case, then a CDR record should be created with a disposition of "NO ANSWER".  There is an existing bug where the disposition may be "BUSY" in this case, but either way, the only way a CDR record will exist is if you allow unanswered calls to be logged.

Reading the definition of the unanswered setting:
"In brief, this option controls the reporting of unanswered calls which only have an A  party. Calls which get offered to an outgoing line, but are unanswered, are still logged, and that is the intended behaviour. (It also results in some B side CDRs being output, as they have the B side channel as their source channel, and no destination  channel.)"

If a queue caller calls into a queue and no agent picks them up, then the caller was never bridged with another channel, i.e., there was no B side channel.  They explicitly fall into the unanswered scenario.

As it is, this does not appear to be a bug, so long as a CDR record appears when you have unanswered=yes.



> No CDR when queue call hangs up while ringing agent and 2 or more agents in that queue are busy
> -----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20151
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20151
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 1.8.11.1, 10.6.1
>         Environment: Debian
>            Reporter: millsu2
>            Assignee: Rusty Newton
>            Severity: Minor
>         Attachments: debug.log
>
>
> When a call rings in to a queue with at least one available agent and at least 2 busy agents no CDR record is generated if the caller hangs up while ringing the free agent. I tested this with both 5 and 3 agents in the queue.
> It does this regardless if endbeforehexten=yes or endbeforehexten=no. I did not test with unanswered=yes since that will mess up our CDR's.
> I can recreate the problem in Asterisk 10.6.1 by creating a queue called 'test', adding 3 queue members through AddQueueMember, making 2 of them busy by calling an outside line or calling each other, then putting a call in the queue. The queue will ring the free agent. While it is ringing, before the agent answers, the queue caller hangs up.
> At this point a CDR should be created for this call in all configured cdr back ends, but none is created either in the CSV file, the pgsql database or throguh odbc to pgsql.
> While gathering the logfile data, I noticed it was trying to log only to sqlite, which I didn't know was enabled.I checked that db file and the CDR's were correctly logged there. I turned off sqlite and tested again, but the CDR is now not logged anywhere.
> The attached debug log was done on a test machine with no activity so it mostly only includes info about the specific call (timestamp: Jul 20 14:30:38)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira