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

Rusty Newton (JIRA) noreply at issues.asterisk.org
Thu Feb 14 09:12:59 CST 2013


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

Rusty Newton closed ASTERISK-20974.
-----------------------------------

    Resolution: Suspended
    
> 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: Rusty Newton
>
> 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



More information about the asterisk-bugs mailing list