[asterisk-bugs] [JIRA] (ASTERISK-20742) [patch] Log callers entering/leaving MOH.
Steve Murphy (JIRA)
noreply at issues.asterisk.org
Thu Nov 29 08:15:45 CST 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-20742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200236#comment-200236 ]
Steve Murphy commented on ASTERISK-20742:
-----------------------------------------
Richard-- I'm not setting precedent here. It was set in chan_agent. You haven't explained why it is imperative that channels NOT be accessed to make queue logging throughout the core of Asterisk OK. It seems a rather arbitrary measure, and not even practical.
CEL exists because there was/is a huge problem with CDR's: you simply cannot store the dual-channel information that CDRs require on a single channel. You have to store it outside any channel. So, CEL gave us a way to store the channel events "offline". Trouble is, CEL can do the storage, but no-one (afaict) has finished the process and written a CEL->CDR converter/generator. I was going to, but economics got in the way. Right now, CEL is a cool thing, but almost useless until the second half is written. (there may be a few individuals doing this on their own out there somewhere, who knows).
CEL was never meant as a logging unification solution... but, sure, it could be. I'm not sold on the fact that unifying logging would be beneficial over what we have now. It certainly won't be more efficient. So until then, we have AMI log events to port 5038, we have CDR's being logged to databases/log files, CEL being logged to databases/log files, we have random events logged to console/files, and we have the queue_log.
Queue_log has been lucky to require very little in the way of events outside of app_queue. But there was never any guarantee that it someday would not. And here is one of those days. The need for hold information is out there, and this patch supports
it in a fairly minimal, simplistic way, without breaking any precedents or introducing any new dependencies. The need is for real-time reporting.
We can't simply try to force users to use other mechanisms, either. MOH is information is already published via AMI. But there are packages out there that don't use AMI, that do use queue_log. And it would be horribly inefficient to have them open the AMI and monitor it for just HOH events. Asterisk can't handle very many AMI connections.
So, let's get practical. Anyone else out there want to throw in their opinion?
> [patch] Log callers entering/leaving MOH.
> -----------------------------------------
>
> Key: ASTERISK-20742
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-20742
> Project: Asterisk
> Issue Type: New Feature
> Security Level: None
> Components: Applications/app_queue
> Affects Versions: SVN, 12
> Environment: all
> Reporter: Steve Murphy
> Severity: Trivial
> Attachments: qonhold.trunk.diff, qonholdv2.trunk.diff
>
>
> This patch will allow incoming calls to track the time they are put on hold (MOH). This does not count MOH played before an agent accepts the call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list