Asterisk
  1. Asterisk
  2. ASTERISK-20504

Asterisk 1.8 should use [compat] section in asterisk.conf and behave acconding to the flag pbx_realtime=1.6

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Severity: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: 1.8.16.0
    • Target Release Version/s: None
    • Security Level: None
    • Labels:
      None
    • Environment:
      Debian wheezy, mysql (using addon res_config_mysql)
    • Regression:
      Yes

      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'

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          Hide
          Matt Jordan added a comment -

          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.

          Show
          Matt Jordan added a comment - 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.
          Hide
          Tiago Geada added a comment -

          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?

          Show
          Tiago Geada added a comment - 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?
          Hide
          Matt Jordan added a comment -

          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.

          Show
          Matt Jordan added a comment - 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.
          Hide
          Tiago Geada added a comment - - edited

          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.

          Show
          Tiago Geada added a comment - - edited 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.
          Hide
          Tiago Geada added a comment - - edited

          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:

                          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
          

          where macro is:

          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;
          }
          
          Show
          Tiago Geada added a comment - - edited 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: 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 where macro is: 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; }
          Hide
          Rusty Newton added a comment - - edited

          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

          Show
          Rusty Newton added a comment - - edited 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

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development