Based on the line number of that error in chan_sip.c, it looks like you're running Asterisk 1.8 or earlier.
AFAIK, The issue you are seeing was fixed years ago, but not THAT many years ago! If I'm right, you should upgrade to fix that issue. Cheers, Steve On Fri, 30 Jun 2017 at 13:39 Stefan Viljoen <viljo...@verishare.co.za> wrote: > Hi guys > > > > Does anybody have any opinion on what causes tens of thousands of these > messages per hour to pop up in the CLI: > > > > [Jun 30 14:24:59] WARNING[2209]: chan_sip.c:4057 __sip_autodestruct: > Autodestruct on dialog '7e9597ae6ce95fef23374f4b380a9b70@192.168.0.1:5060' > with owner SIP/1148-0005bb2d in place (Method: BYE). Rescheduling > destruction for 10000 ms > > [Jun 30 14:25:01] WARNING[2209]: chan_sip.c:4057 __sip_autodestruct: > Autodestruct on dialog '6faefcc24547f1e774864ca87e3ff335@192.168.0.1:5060' > with owner SIP/1028-0005bb3f in place (Method: BYE). Rescheduling > destruction for 10000 ms > > [Jun 30 14:25:02] WARNING[2209]: chan_sip.c:4057 __sip_autodestruct: > Autodestruct on dialog '0d64480f4052a9e9054153552f1af7ba@192.168.0.1:5060' > with owner SIP/1412-0005bb5d in place (Method: BYE). Rescheduling > destruction for 10000 ms > > > > Symptoms are that an extension will dial, converse and hang up, but then > be unable to dial for up to four minutes after the initial call that > extension made - all the while thousands of the above messages scroll by in > the CLI. Along with then hundreds of “too many calls” warnings for each > extension which are limited to 1 call per extension at a time in sip.conf > > > > I’ve googled intensively, no AGI is being run, hangup literally calls > Hangup(). I’ve already disabled and unloaded CDR-TDS, and ODBC CEL and CDR > logging to MySQL (in case db issues are causing a lock or something when > writing CDRs) > > > > I see on big G that many many people have had this issue, but nowhere is > there any kind of concrete end result or answer to any of the questions. > This has started to happen at our site this Monday... it comes and goes > driven by no factor I can determine, except maybe workload. Server load > average when this is going on is 8 in top for a quad-Core i7 machine with > Centos 7 and 8GB of RAM, but the machine has hit 16 as load avg without > this happening. It also sometimes happens with the load average at 4 or > less... > > > > The particular server has been running undisturbed for about three years > and has handled tens of millions of calls, and only this Monday started > exhibiting this behaviour. The dialplan was last changed about three months > (and about 3 million calls) ago. > > > > Any body got ANY advice or ideas where I can begin to diagnose this? > > > > Thanks, > > > > Stefan > > > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users