[asterisk-bugs] [JIRA] Commented: (ASTERISK-17776) No CDR record is generated if caller hangs up while in Queue and members are busy. Reproduced in 1.8 and 1.6 as well.
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Tue Jul 24 17:43:21 CDT 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-17776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195174#comment-195174 ]
Matt Jordan commented on ASTERISK-17776:
----------------------------------------
So, there's no question that CDR records in Queue are ... interesting. I won't claim that I can define all of the behavior, since CDR behavior is quirky in general, and there are lots of permutations for how a caller in a queue can end up.
Starting at the beginning: why does the Answer application not write the CDR entry?
Well, the Answer dialplan application is going to do what you think here, it just happens to get nuked later by the Queue application. While it will Answer the call and set the CDR disposition to "ANSWERED", subsequently, the Queue application is going to mark the CDR record as "NO ANSWER" (or "BUSY", or something indicating failure). This disposition overwrites the "ANSWERED" disposition that was previously set.
Without the unanswered=yes flag, this record is not written to the CDR.
The All Paused situation is interesting. This happens to occur because, when all queue members are paused, no one bothers to update the CDR disposition. If you have an Answer() before the Queue() application, you'll get a disposition of "ANSWERED", even though all queue members are paused and no one answered the call. If you don't have an Answer() application call before the Queue() application, you'll get the expected result of "NO ANSWER" (assuming you have unanswered=yes), since no one updated the CDR entry and no one answered the call.
The correct result here should be that if all Queue members are paused - regardless of the presence of the Answer dialplan application - the result is "NO ANSWER" - which again, would not write an entry to the CDR record without the "unanswered=yes" flag.
So, there's a bug here, but its more in the inconsistency of what happens with paused queue members.
As Jeff recommended, you're probably better off relying on the queue log, rather then CDRs, to determine what happens with a call in the queue (which is part of the reason why the queue log exists in the first place).
> No CDR record is generated if caller hangs up while in Queue and members are busy. Reproduced in 1.8 and 1.6 as well.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-17776
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-17776
> Project: Asterisk
> Issue Type: Bug
> Components: Applications/app_queue
> Affects Versions: 1.8.3
> Reporter: Attila Megyeri
>
> SIP endpoint (SIP/oatest01) is added as member to Queue "oatest" with penalty 1.
> Sip endpoint oatest01 is Busy (talking).
> A new call is inserted into queue "oatest".
> Console says
> -- Got SIP response 486 "Busy Here" back from <Masked IP>
> -- SIP/oademo01-00000043 is busy
> Caller hangs up.
> No CDR record is created either in the DB or in the file system.
> In other words, NO INFO at all about a missed call...
> ****** ADDITIONAL INFORMATION ******
> Very simple to reproduce.
> Create a queue
> -----
> [oademo]
> strategy=rrmemory ;ringall
> context=oademo-voicemail
> setinterfacevar=yes
> setqueuevar=yes
> updatecdr=yes
> ringinuse=no
> joinempty=no
> membermacro=oademo-member
> ----------
> Add a member to a queue, with penalty 1
> ----
> queue add member SIP/oademo01 to oademo penalty 1
> ----
> Make the member busy (has a call).
> Enqueue a call into the queue:
> exten => 223344,1, NoOp(Queue CDR debug extension)
> exten => 223344,n, Ringing()
> exten => 223344,n, Wait(1)
> exten => 223344,n, Answer()
> exten => 223344,n, Queue(oademo,R,,,240)
> Disconnect the call that is waiting in the queue.
> Check the CDR - there will be no track of the call.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list