| Summary: | ASTERISK-09656: many unnecessary CDRs using Queue cmd | ||
| Reporter: | drrt (drrt) | Labels: | |
| Date Opened: | 2007-06-12 05:50:17 | Date Closed: | 2011-06-07 14:07:53 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) debug ( 1) debug1 ( 2) queues.conf | |
| Description: | Using psql as CDR storage at the moment. I noticed many odd CDRs at my storage after update from 1.4.0 to 1.4.3(1.4.4). The looks always similar with 2 different values. Attached files describe asterisk system adding CDRs when nobody picks up a phone in a queue. | ||
| Comments: | By: Steve Murphy (murf) 2007-06-12 16:10:06 Yes, the fixes to make other things work cause this problem to pop up; attempts to ring phones are now showing up as UNANSWERED calls in the CDR dbs. Is it a big problem to ignore UNANSWERED CDR's? If unanswered CDRs are truly useless to everyone, I could institute a filter; do you think this is the case? By: drrt (drrt) 2007-06-13 15:19:13 thx for advice. i just wonder about the source. you gave me the clue about such behavior. hope you'll find the way to fix this. By: Steve Murphy (murf) 2007-06-13 15:59:49 One other thought that occurred to me-- could it be, if nobody in the queue answers a call, that this would be the situation? The disposition would be set to UNANSWERED if everyone rang, but noone answered. If this is the case, you may not want to just ignore such calls-- they are an indication that nobody was in the office, I guess. An indication you need to extend your office hours, perhaps? By: drrt (drrt) 2007-06-15 02:33:14 you are absolutely right but the behavior havent documented then i just saw what i saw. now i got your point and made some changes By: Steve Murphy (murf) 2007-06-18 18:36:32 OK, then, I'm going to close this bug; but just so you know, I am working on major changes to the current CDR system in the trunk version of Asterisk, via my branch, team/murf/CDRfix5, to generate CDR's when conversations take place, via monitoring the bridging going on, rather than blindly generating CDR's when hangups occur. This will be a major change. Since CDR's are not generated by hangups, then forkCDR() is useless, as it relied on hangups to post and free the CDR's. Instead, I now have the CDR_CONTROL() function, which will give you complete control over CDR generation in the dialplan. So, the winds of fortune (pardon any possible puns here) are changing, hopefully for the better. | ||