[Home]

Summary:ASTERISK-20504: Asterisk 1.8 should use [compat] section in asterisk.conf and behave acconding to the flag pbx_realtime=1.6
Reporter:Tiago Geada (cusco)Labels:
Date Opened:2012-10-02 14:19:46Date Closed:2012-10-17 14:52:02
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Addons/res_config_mysql Applications/app_queue
Versions:1.8.16.0 Frequency of
Occurrence
Related
Issues:
is caused byASTERISK-17036 [patch] Output of queue_log stopped after several hours
is caused byASTERISK-15863 [patch] Improve realtime queue logging
Environment:Debian wheezy, mysql (using addon res_config_mysql)Attachments:
Description:in 1.6 queue_log was being populated with the column 'time' formated as UNIX TIME STAMP, while in 1.8, res_config starts by complaining about column time being varchar(11) while it should be char(26) and every queue event is registered with datetime format (as in '2012-10-02 00:01:04') instead of '1349132464'

I thought in asterisk.conf [compat] section having "pbx_realtime=1.6" would take care of this, but it does not.

Shouldn't date be inserted as unixtimestamp, if this compat flag is set to 1.6 ??


Also, maintaining this compatibility, queue_log should still need only one 'data' column, instead of 'data1','data2','data3','data4' and 'data5'
Comments:By: Matt Jordan (mjordan) 2012-10-02 14:40:01.289-0500

So, this issue was caused by several changes that were made to the Queue Log during the 1.6.x timeframe.  These should have been noted in the UPGRADE and/or CHANGES file; unfortunately, they were not.  The mysql queue_log.sql file was updated with the appropriate schema changes - however, that is not sufficient to support a breaking schema change.

That being said, this issue has already caused multiple regressions as the behavior was 'tweaked' from patch to patch.  I'm not in favor of having to tweak it yet again in order to support the older schema.  While I agree that it is a pain, if at all possible, the database should be updated to reflect the new schema delivered in 1.6.2.

By: Tiago Geada (cusco) 2012-10-02 21:25:21.608-0500

Hello. It is understandable that a regression is not desired, since datetime is easier to work with. However, when a structure is built arround the old schema, one can not upgrade to 1.8 unless he upgrades the same structure relying on the 'unix time stamp' schema.

instead of tweaking, could this queue_log reflect old behaviour when [comapt] section states so?

By: Matt Jordan (mjordan) 2012-10-03 09:12:13.504-0500

What structure are you referring to?  Is it something that you wrote around the old schema?

As I previously stated, making the queue_log change its behavior and expect a different schema when a compatibility flag introduces yet another point for further regressions, not to mention that putting in (yet another) flag into the {{[compat]}} section is never ideal.

In order to justify that change, I'd like to understand what is preventing you from updating your system to the new schema.

By: Tiago Geada (cusco) 2012-10-03 14:19:53.754-0500

Well...

We are a call center that started small and grown wide in a short time window. We use queue_log to read stuff about calls. For instance our 'panel board' in java reads AMI events, but has a few stats readings from queue_log such as count ABANDON, ENTERQUEUE events do show some numbers.

Our call reports, are also read from queue_log, to know number of calls lost before wating 15 seconds, or after or whatever. These reports are pretty big and its a module per partner...

Even asterisk AEL's do write custom stuff (such as 'INCOMING', 'OUTGOING' 'HUNGUP') using internal variable ${EPOCH}
Even recorded calls path is written in queue_log ... All about our PBX comes from (and goes into) queue_log table.

Today we also use CDR, however, only new apps/scripts read from there, and everything else we heavily relly on, is using queue_log.


Some aplications do get deprecated, and replacements are using CDR, but we simply can not change all of it. We are always too busy with whatever else comes along.

As for me, I would like to upgrade asterisk, but it is not essential. If there is no backwards compatibility we will not upgrade, unless it becomes really necessary for some reason...

Also, issue ASTERISK-17036 seems to be affecting only text file.

I must state, in the past we used to change sourcecode ( there was a }else{ to chose between RT queue_log or file quele_log) to keep both text file and mysql queue_log. Today however we no longer need the text file.

By: Tiago Geada (cusco) 2012-10-03 14:30:54.365-0500

just to show you...

debianastk:/etc/asterisk# grep Queue_log extensions_partner/*ael|wc -l
81

debianastk:/etc/asterisk# grep "Queue_log" extensions_services.ael|wc -l
58

this is stuff like:
{noformat}
               Set(data=${PARTNER}|${STARTED}|${CALLERID(dnid)}|${CALLERID(num)}|${remoteUniqueID}|${GEO}|${recording-path}); Set(CDR(data)=${data});
&Queue_log(${UNIQUEID},${PARTNER},${CHANNEL},INCOMING,${data});         // Log it to csr_queue
{noformat}


where macro is:

{noformat}
macro Queue_log(mUNIQUEID,mPARTN,mCHANNEL,mEVENT,data)  // log in queue_log and in mysql csr_queue
{
       if("${LEN(${mEXT})}" == "3"){
               MYSQL(Query resultid ${connid_pbx} SELECT agent FROM queue_member_table WHERE membername=${mEXT} LIMIT 1);
               MYSQL(Fetch fetchid ${resultid} agentName);
               MYSQL(Clear ${resultid});
               Set(CDR(agent)=${agentName});
       }
       MYSQL(Query resultid ${connid_pbx} INSERT INTO csr_queue(time,callid,queuename,agent,event,data) VALUES(${EPOCH},'${mUNIQUEID}','${mPARTN}','${mEXT}','${mEVENT$

       MYSQL(Disconnect ${connid_pbx});

       return;
}
{noformat}




By: Rusty Newton (rnewton) 2012-10-17 14:52:02.314-0500

This is being close as a feature request or improvement, with no patch. If someone provides a patch for the requested functionality for queue_log backwards compatibility then the issue can be re-opened by contacting a developer in #asterisk-bugs or the asterisk-dev mailing list.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines