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

[Matt Jordan]

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

(Updated Aug. 17, 2012, 9:14 a.m.)


Review request for Asterisk Developers.


Changes
-------

After thinking about the objections raised by Tilghman, Paul, and Leif, I think they are right: this patch has too much risk of changing behavior in app_queue to have it go into 1.8.  So I've rewritten the patch for trunk (12).

This patch does a few things slightly differently then the previous take.

1. It now only sets the CDR status to NO ANSWER if the calling channel has not been answered.  This addresses some of Tilghman's concern, wherein a channel that is answered prior to going into the Queue would have its CDR status overwritten.  This is now no longer the case.

2. It moves the setting of the CDR status to BUSY from ring_entry to wait_for_answer.  Setting the CDR status in ring_entry assumes that if any queue member is busy, that the overall CDR status should be BUSY.  This has been the chief complaint of people who have reported issues regarding this behavior.  Now we only set the CDR status to busy if all queue members are busy or otherwise unavailable.

Testing done:

1. All tests on https://reviewboard.asterisk.org/r/2063/ pass.  Note that these tests help to define the behavior for future versions.
2. Tested with Answer() before Queue.  CDR record created as a result of answering the channel was left undisturbed.
3. Tested with:
  a) No queue members paused, caller unanswered, queue times out.  Results in disposition of no answer.
  b) No queue members paused, caller hangs up.  Results in disposition of no answer.
  c) One queue member paused, caller unanswered, queue times out.  Results in disposition of no answer.
  d) One queue member paused, caller hangs up.  Results in disposition of no answer.
  e) One queue member paused, one on bridged call with some other caller.  Caller unanswered, queue times out.  Results in disposition of busy.
  f) One queue member paused, one on bridged call with some other caller.  Caller unanswered, caller hangs up.  Results in disposition of busy.
  g) All queue members paused.  Caller hangs up.  Results in disposition of no answer.
  h) All queue members paused.  Caller times out.  Results in disposition of no answer.

Note that the behavior that is changed from the current operation is what happens when a queue member is paused, at least one queue member is available, and a caller times out or hangs up.  This patch changes it to be consistent with the behavior of what occurs when all queue members are paused.


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 (updated)
-----

  /trunk/UPGRADE.txt 371383 
  /trunk/apps/app_queue.c 371383 

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/20120817/b5db82ef/attachment-0001.htm>