[asterisk-bugs] [JIRA] Commented: (ASTERISK-20416) Autodestruct warnings spamming CLI and extension to extension calls not possible after problem forces maximum calls limit reached at 500 calls

aragon (JIRA) noreply at issues.asterisk.org
Tue Oct 2 08:20:27 CDT 2012


    [ https://issues.asterisk.org/jira/browse/ASTERISK-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197829#comment-197829 ] 

aragon commented on ASTERISK-20416:
-----------------------------------

Someone on my team came across this reference.
http://forums.asterisk.org/viewtopic.php?f=1&t=80755&p=166484&hilit=chan_sip.c%3A+Autodestruct+on+dialog#p166484

We don't use RADIUS on our systems but I speculate the other comments in this thread (regarding BYE's) are applicable to what is going on here.
We are using cdr_adaptive_odbc

I quote:
'1. When a call (either inbound or outbound...doesn't matter which leg of the call) is in progress, and one of the legs hangs up, Asterisk just sits there like a lump without sending a BYE message to the remaining active channel.

2. If you wait and watch, and the remaining channel keeps its RTP stream to Asterisk open (phone off-hook still), the remaining leg will FINALLY get sent a BYE from Asterisk exactly 30 seconds after the first leg hangs up. It doesn't matter how long the call lasted (seconds or hours), you can count on needing to wait 30 seconds from the instant the first channel is dead. When this happens, the channel is cleaned up as expected.

3. If you hang up the remaining channel (put phone back on-hook) BEFORE 30 seconds are up, Asterisk really doesn't like this. A few seconds after you do this, you will see a "WARNING: chan_sip.c: __sip_autodestruct: Autodestruct on dialog '[...]' with owner in place (Method: BYE)" show on the console, and the BYE dialog will remain "stuck" in 'sip show channels' until you restart Asterisk. After a while, these really begin to accumulate.'

So without being an expert I assume we lock the CDR tables and the ODBC driver is locked waiting for Asterisk to hang up the orphaned leg.

This is what our cdr_pre locking script looks like

Index: cron/cdr.php
===================================================================
--- cron/cdr.php        (revision 9992)
+++ cron/cdr.php        (working copy)
@@ -1,8 +1,27 @@
 <?php
+function isTableLocked($table) {
+
+    global $asterisk;
+
+    $sql = "SHOW OPEN TABLES WHERE In_use > 0 like '$table'";
+    $res = $asterisk->_db_report_read->query($sql);
+    $r = $res->fetchRow(DB_FETCHMODE_ASSOC);
+
+    if (!is_null($r)) {
+       print " * TABLE '$table' IS LOCKED ...\n";
+       return true;
+    }
+    return false;
+}
+
 function FixCDRTenant($table = 'cdr') {
     global $asterisk;
+    if (isTableLocked($table)) {
+       return false;
+    }
+
     $sql = "SELECT channel,dstchannel,dcontext,uniqueid FROM $table WHERE tenant IS NULL OR tenant = ''";
     $res = $asterisk->_db_report_read->query($sql);
@@ -44,6 +63,10 @@
 function FixCDRLocation($table = 'cdr') {
     global $asterisk;
+
+    if (isTableLocked($table)) {
+       return false;
+    }
     $sql = "SELECT dst,dstchannel,uniqueid FROM $table WHERE location IS NULL OR location = ''";
     $res = $asterisk->_db_report_read->query($sql);
@@ -88,11 +111,18 @@
     // *******************************************************************
     print "- Move data from CDR-pre to the CDR table\n";
+    if (isTableLocked('cdr_pre')) {
+       return false;
+    }
+
+    $asterisk->_db_report_write->query("LOCK TABLES cdr_pre WRITE");
+
     $sql = "SELECT * FROM cdr_pre";
     $res = $asterisk->_db_report_read->query($sql);
     if (is_a($res, 'PEAR_Error')) {
        print " - ERROR GETTING DATA FROM DATABASE\n";
+       $asterisk->_db_report_write->query("UNLOCK TABLES");
        return false;
     }
@@ -122,5 +152,8 @@
        $sql = "DELETE FROM cdr_pre WHERE uniqueid = " . $asterisk->_db->quote($r['uniqueid']);
        $asterisk->_db_report_write->query($sql);
     }
+
+    $asterisk->_db_report_write->query("UNLOCK TABLES");
+
     print ".";
 }

> Autodestruct warnings spamming CLI and extension to extension calls not possible after problem forces maximum calls limit reached at 500 calls
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20416
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20416
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_local
>    Affects Versions: SVN
>         Environment: Centos 5.8 x64 quadcore 8 GB RAM
>            Reporter: aragon
>            Assignee: aragon
>            Severity: Critical
>         Attachments: asterisk.stack.txt, autodestructverbosecli2.txt, autodestructverbosecli.txt, cli_debug_autodestruct.rar, cli_debug_autodestruct.rar, log.rar
>
>
> Every single day Asterisk cannot complete transfers or local extensions cannot call.
> While incoming and outgoing calls are working...
> Autodestruct warnings spam the CLI with hundreds of WARNINGS per minute.
> Local calls become possible only after the Autodestruct messages go away or Asterisk is restarted.
> It is speculated that Autodestructs frequently occur during dynamic ACD logins or outgoing calls requiring PINs so this could be related to some ast_waitfordigit issue discovered at ASTERISK-20375.
> All incoming calls terminate to ACD queue.
> All outgoing calls require a PIN to complete.
> No IVR's in use.
> No DTMF *2 transfers being done by users.
> Opening a new ticket since I am not 100% sure they are related issues.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list