| Summary: | ASTERISK-20974: chan_iax2 messing with stale channels | ||
| Reporter: | mgrobecker (mgrobecker) | Labels: | |
| Date Opened: | 2013-01-23 02:08:16.000-0600 | Date Closed: | 2013-02-14 09:12:26.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Addons/res_config_mysql Channels/chan_iax2 |
| Versions: | 1.8.19.1 | Frequency of Occurrence | Frequent |
| Related Issues: | |||
| Environment: | Debian Squeeze x64 | Attachments: | |
| Description: | After upgrading to 1.8.19.1 I experienced heavy problems with stale IAX2 channels (> 2k not responding channels) which caused Asterisk to not respond to IAX2 clients.
On the cli I found hundreds of repeating messages saying: {noformat} WARNING[17816] chan_iax2.c: Max retries exceeded to host 188.xxx.xxx.xxx on IAX2/188.xxx.xxx.xxx:5036-13267 (type = 6, subclass = 11, ts=2069930, seqno=54) WARNING[17813] chan_iax2.c: Max retries exceeded to host 188.xxx.xxx.xxx on IAX2/188.xxx.xxx.xxx:5036-2003 (type = 6, subclass = 11, ts=1519957, seqno=226) WARNING[17817] chan_iax2.c: Max retries exceeded to host 188.xxx.xxx.xxx on IAX2/188.xxx.xxx.xxx:5036-15003 (type = 6, subclass = 2, ts=1238996, seqno=190) WARNING[17815] channel.c: Exceptionally long voice queue length queuing to IAX2/188.xxx.xxx.xxx:5036-9768 WARNING[17811] chan_iax2.c: Max retries exceeded to host 79.xxx.xxx.xxx on IAX2/xxxxxxxx-4771 (type = 6, subclass = 11, ts=1159963, seqno=171) {noformat} The system where this occured has about 200 registered IAX2 peers with MySQL realtime. iax.conf has following entries: {noformat} notransfer=yes transfer=no calltokenoptional=0.0.0.0/0.0.0.0 requirecalltoken=no autokill=no rtcachefriends=on qualify=2000 codecpriority=host delayreject=yes adsi=no encryption=no forceencryption=no iaxcompat=yes srvlookup=yes trunk=yes trunkmtu=1240 trunkfreq=20 trunktimestamps=yes {noformat} Also with "autokill=yes" the same thing happened. The only way to get rid of the channels is to restart Asterisk - but about 20 hours later I got a déjà-vu. Since Asterisk did not crashed (so i have no core dump) and I can't reproduce this easily with only a few active peers I'm unfortunately unable to provide a full debug trace :-( With Asterisk 1.8.15-cert1 the problem does not occur - but I got the error message "ast_db_get failed to retrieve iax/provisioning/cache". Maybe it has something to do with ASTERISK-20337? | ||
| Comments: | By: Rusty Newton (rnewton) 2013-01-27 16:36:04.552-0600 {quote} Since Asterisk did not crashed (so i have no core dump) and I can't reproduce this easily with only a few active peers I'm unfortunately unable to provide a full debug trace {quote} I understand you can't provide a backtrace without a core dump. Are you able to turn on an Asterisk full log with VERBOSE and DEBUG at level 5? The developers would want to see a log showing the time right when the issue start occurring. Without this, there is not much anyone can do. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information {quote} With Asterisk 1.8.15-cert1 the problem does not occur - but I got the error message "ast_db_get failed to retrieve iax/provisioning/cache". Maybe it has something to do with ASTERISK-20337? {quote} Sure, the issue could be related to changes made between an older version and the one you are using now, but guessing isn't useful. Developers will need to see debug and preferably even a packet capture of a stuck channel to identify the issue. After seeing debug, a developer may really need to get a backtrace captured during running. https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock An additional note is that pbx_realtime is under extended support and therefore supported by the community. If this issue points at pbx_realtime, then response times on this issue will reflect that. By: Rusty Newton (rnewton) 2013-02-14 09:12:14.094-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines | ||