[asterisk-bugs] [JIRA] (ASTERISK-20974) chan_iax2 messing with stale channels

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-20974:
------------------------------------

    Assignee: mgrobecker
      Status: Waiting for Feedback  (was: Triage)

{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.
                
> chan_iax2 messing with stale channels
> -------------------------------------
>
>                 Key: ASTERISK-20974
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20974
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Addons/res_config_mysql, Channels/chan_iax2
>    Affects Versions: 1.8.19.1
>         Environment: Debian Squeeze x64
>            Reporter: mgrobecker
>            Assignee: mgrobecker
>
> 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?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira