[asterisk-dev] Tracking MOH on queues - ASTERISK-20742

[Matthew Jordan]

On 12/07/2012 07:02 AM, Lenz Emilitri wrote:
> Hello all,
> I am posting this message following Leif's suggestion on
> https://issues.asterisk.org/jira/browse/ASTERISK-20742 that the patch
> submitted by Steve Murphy in order to track MOH events happening on
> queues should have a wider discussion.
> 
> The patch was written so that it would be possible to track MOH events
> happening on queues on the queue_log - this is something I would be
> personally very interested in, as it is one of the typical feature
> requests we get for call-center statistics, and it is currently not
> trivial to implement in Asterisk; so I believe it could add shared value
> to Asterisk.
> 
> The discussion on the patch was about whether it would be okay or not to
> have a spread of knowledge between app_queue and res_musiconhold - in my
> opinion that makes sense as MOH events have special, defined interest in
> the context of being on a queued call, but the discussion is open.
> 

I'm fine with the concept, but the implementation is definitely not an
approach I'd advocate.

Adding channel variables that a loadable module sets, so that other
loadable modules can check it, creates weak dependencies between those
modules. If, in the future, we replaced or significantly refactored
res_musiconhold or app_queue, the functionality would certainly break.
There are other possible approaches, as Richard has outlined:

"What I was trying to get across was to make res_musiconhold always
queue_log when a channel starts and stops playing MOH. This way
res_musiconhold is still independent of app_queue because
res_musiconhold does not get any information from app_queue to produce
its logs. Then like CEL you can do post processing on queue_log to
determine the length of time a caller was placed on hold."

With Richard's suggestion, ast_queue_log would have to determine if the
channel was in a queue, and explicitly not create a log entry if the
channel was not in a queue.

There are a number of other ways this could be implemented as well.
res_musiconhold could implement a function table that lets other modules
add an observer to be notified when MOH is started/stopped. Then,
app_queue would be notified when MOH started/stopped, and it could
update the queue log itself. While such a system would still 'break' if
res_musiconhold was changed, app_queue could detect that the
subscription wasn't implemented and warn the user that it would not log
MOH events. This is certainly more desirable than silently failing.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org