[asterisk-dev] [Code Review]: Ensure that CDRs for a caller in a Queue who is not answered is NO ANSWER

[Matt Jordan]

> On July 25, 2012, 7:36 p.m., Paul Belanger wrote:
> > Do we want to change the behaviour of CDRs yet again (especially in a release branch)?  IIRC each time we do, it has always been an issue at a later date.
> > 
> > If yes, my vote would be in trunk only.

I'm not sure I'd see this as being a 'change in behavior', unless you classify a change in behavior as anything that fixes a bug.

Let's look at the current behavior when a caller enters a queue:

1. No one answers, and no member is busy or paused.  If you Answer the inbound channel before it enters the Queue, this will be logged as "ANSWERED"; otherwise it will be logged as unanswered with a disposition of "NO ANSWER".

2. No one answers, at least one member is busy or paused, and at least one member is not busy or paused.  Regardless of whether or not you answer the inbound channel before it enters the Queue, the call will be treated as unanswered and logged with a disposition of "BUSY".

3. No one answers, and all queue members are busy or paused.  Again, if you Answer the inbound channel before it enters the Queue, this will be logged as "ANSWERED"; otherwise it will be logged as unanswered with a disposition of "NO ANSWER".

This behavior is by no means consistent.  There have been several issues filed in relation to this behavior - ASTERISK-17776 and ASTERISK-20151.  (Granted, one of the chief complaints in these issues is that unanswered calls with no B party are not showing up in the CDR logs, but that behavior at least is well defined).

This patch, if anything, brings the disposition behavior closer in line with the behavior of CDRs in other applications where multiple parties are dialed.

On the note of 'we aren't fixing CDRs', I'm perfectly fine with us not fixing certain CDR issues, namely those where the behavior of the CDR cannot be defined because there is no consensus on what the correct behavior should be, and we
cannot reach a consensus due to multiple differing opinions.  In this case, however, the current behavior seems to be wrong by any definition.  If you were relying on using Answer() before the Queue() to get some CDR record, you'd end up with CDR records with a disposition of ANSWERED when no one answered, and you would fail to get CDR records in other cases - which gives you completely
unpredictable behavior.  If you had unanswered=yes with no Answer() before the Queue() application call, you'd end up with CDR records with inconsistent dispositions. In any scenario, predictability of the records with respect to the state of the system is shot.

I would be happy to note the change in the UPGRADE notes, but not fixing any bugs in CDRs seems rather defeatist to me.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2064/#review6814
-----------------------------------------------------------


On July 25, 2012, 4:54 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2064/
> -----------------------------------------------------------
> 
> (Updated July 25, 2012, 4:54 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When a caller enters a queue and no queue member answers the call, some odd behavior can be reporter in the resulting CDR records, depending on the state of certain queue members.
> 
> * If no queue members are paused, the CDR result is whatever the result was prior to going into app_queue.  If the call was answered, this is ANSWERED; otherwise, it is NO ANSWER.
> * If some queue members are paused, the CDR result is BUSY.  This patch changes this to NO ANSWER.
> * If all queue members are paused, the CDR result is again whatever the result was prior to going into app_queue.
> * If the caller hangs up, times out, or presses '*' with the 'h' option, the result is again not set.
> 
> Similar to app_dial, if the caller in the queue does not get answered, we should set the CDR record appropriately.  In general, for the scenarios listed above, this is NO ANSWER.
> 
> This patch is a only slightly modified version of the one supplied by the issue reporter.
> 
> Since this is arguably a change in behavior, some tests were written to cover portions of this behavior in https://reviewboard.asterisk.org/r/2063.
> 
> 
> This addresses bug AST-906.
>     https://issues.asterisk.org/jira/browse/AST-906
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/apps/app_queue.c 370418 
> 
> Diff: https://reviewboard.asterisk.org/r/2064/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120726/027aba8f/attachment.htm>