[asterisk-bugs] [Asterisk 0017625]: "I should never be called!" message printed from channels/chan_iax2.c

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17625 
====================================================================== 
Reported By:                vieri
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17625
Category:                   Channels/chan_iax2
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.31 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-12 04:21 CDT
Last Modified:              2010-07-12 12:49 CDT
====================================================================== 
Summary:                    "I should never be called!" message printed from
channels/chan_iax2.c
Description: 
Hi,

Recently, one of my Asterisk servers stopped connecting calls and required
a reboot to "fix it" (did not try to restart or reload).

The log showed loads of this message:

NOTICE[302] chan_iax2.c: I should never be called!

This highly repeated message seems to be preceded by something like:

WARNING[10767] channel.c: Exceptionally long voice queue length queuing to
IAX2/coinbound-15879

When this happens it also seems that SIP peers on a gigabit LAN start
going on/offline frequently. So that seems to explain why calls start to
fail. There is absolutely nothing wrong with the network (and switches). I
don't know if it can be a NIC problem on the server but it's strange
because I have SIP peers on different local subnets connected to different
NICs and switches. It would be a terrific coincidence that all 3 NICs I
have on the server failed as well as the 3 switches... The fact that all
went back to normal after rebooting the Asterisk server led me to file a
bug report.

I'd like to know in what circumstances chan_iax2 can log the "I should
never be called!" message in 1.4.31.

When that happens I usually have a lot of messages such as:

NOTICE[10756] chan_sip.c: Peer '7054' is now Lagged. (2819ms / 2000ms)
NOTICE[10756] chan_sip.c: Peer '7054' is now Reachable. (860ms / 2000ms)
NOTICE[10756] chan_sip.c: Peer '7054' is now Lagged. (2003ms / 2000ms)
NOTICE[10756] chan_sip.c: Peer '7054' is now UNREACHABLE!  Last qualify:
3096
NOTICE[10756] chan_sip.c: Peer '7054' is now Lagged. (2131ms / 2000ms)

Any ideas as to what may be happening and what I should do the next time
it does?

Thanks,

Vieri
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0017521 Brief lagginess on IAX2 channels is fatal
====================================================================== 

---------------------------------------------------------------------- 
 (0124517) vieri (reporter) - 2010-07-12 12:49
 https://issues.asterisk.org/view.php?id=17625#c124517 
---------------------------------------------------------------------- 
Bug 17521 seems to imply that:

- it happens only on "slow" connections (slow networks)
- it may disappear on faster servers
- it happens when transcoding G722

In my case:

- all IAX2 connections are on a gigabit LAN. SIP clients are also on a
gigabit LAN except for a remote SIP provider.
- I'm using recent quad-core AMD processors which is more than enough for
my setups.
- In most cases, I'm using IAX2 to link several Asterisk boxes. SIP
clients use these IAX2 trunks to place calls. They are usually alaw, ulaw
and gsm.

I'm not sure if my report is a duplicate.

I can't easily reproduce it.

If my system were to freak out again, what sys/asterisk stats ("core show
locks", etc.) should I gather before rebooting (should do it quickly
because it happens only on my production servers)?

Thanks 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-12 12:49 vieri          Note Added: 0124517                          
======================================================================