Summary:ASTERISK-03552: IAX registration request does not timeout properly
Reporter:muenning (muenning)Labels:
Date Opened:2005-02-20 16:37:08.000-0600Date Closed:2011-06-07 14:05:06
Versions:Frequency of
Description:I have a setup with IAX connection to a location with unreliable internet. In addition my IP address is changing every 24h with about 60 seconds offline time and is by this probably triggering the bug.

Usualy the CLI command "iax2 show registry" shows state "Registered". But after some days it stays to "Request Sent" and no calls are possible. This condition persists for days, probably forever. Apparently at some state of the IAX (re-)registration there is some state without proper timeout.

After restarting (reloading is not enough) asterisk it registers correctly and the state is again "Registered".


I am using Gentoo Linux on both locations. I noticed this behaviour startng with version 1.0.2. My setup started with pre 1.0 versions where I haven't met this behaviour but it's possible that it simply was not noticed. Or maybe because then I restarted asterisk on every reconnect/IP change.

I don't know how to generate the described IAX connection lockup but it occures about once per week. Maybe intentionally disrupting the internet connection and changing IP address would increase the probability.

I assume that a quick check on the registration/re-registration procedure should show where/why this is possible but if you tell me what debugging information can help you finding it I will gladly provide it when it happens again.
Comments:By: Mark Spencer (markster) 2005-02-26 10:26:35.000-0600

Does this problem occur in CVS head?

By: muenning (muenning) 2005-02-27 05:47:35.000-0600

As it is a production system I have to be carefull with trying-it must stay in an operational state :-). I will try CVS head A.S.A.P. after I figure out how to "tweak" it into the system and post the results.

Maybe something more about IAX and communication/timeouts I just noticed, probably connected to the initial problem. Since yesterday there was no IAX connection possible anymore but the iax registry state was "registered" and internet was working. The remote asterisk did not show any connection attempt.

iax show channels in CLI on the local system listed a lot of bogus/"empty" connections like:

Channel               Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  JitBuf  Format
(None)                212.xxx.xxx.xxx  muenning    00001/00000  00002/00000  00000ms  0000ms  0000ms  unknown
(None)                212.xxx.xxx.xxx  muenning    00002/00000  00002/00000  00000ms  0000ms  0000ms  unknown
(None)                212.xxx.xxx.xxx  muenning    00003/00000  00002/00000  00000ms  0000ms  0000ms  unknown

and each call attempt added another one. The list was only growing. As for the timeout - after about a minute waiting on a silent line there was no busy or whatever indication. Maybe there would have been one later but as for unsuccessful iax connection attempts I know that the timeout is shorter.

I made a tcpdump and saw that when dialling there were no packets at all sent to the remote host. Doing a reload in CLI just turned the iax registry state to "Request Sent" and only a restart made it work again.

By: Mark Spencer (markster) 2005-02-27 11:06:17.000-0600

It's possible there is a deadlock.  When you do "iax2 debug" do you still see activity when it's in that state?  If not, you should probably attach gdb to the running asterisk and perform a "thread apply all bt".  Also please confirm this is stock asterisk with no patches or modifications.

By: Mark Spencer (markster) 2005-03-02 23:24:16.000-0600

Hello, please respond regarding the results of iax2 debug when asterisk is in the described state, and if so, please attach gdb and give us a "thread apply all bt" so we can try to locate the source of the issue.  Finally, please confirm your asterisk sources are unpatched / unmodified.  If you are no longer interested in this bug, we can close it out.

By: Mark Spencer (markster) 2005-03-12 00:50:33.000-0600

Suspended due to lack of response from bug placer.