[Home]

Summary:ASTERISK-01172: iax.conf and reload do not play well together
Reporter:timecop (timecop)Labels:
Date Opened:2004-03-08 07:07:38.000-0600Date Closed:2004-09-25 02:49:43
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:editing changes in iax.conf while asterisk is running,
followed by "reload" is not exactly same as editing the
conf, "stop now", and restarting asterisk.
One of such examples is adding trunk=yes to a peer might not
take full desired effect until restart of asterisk. (And if
trunk configuration was wrong, cause failure).
Comments:By: zoa (zoa) 2004-03-08 07:09:57.000-0600

I also noted problems like these.
If its not possible to fix this, is it possible to document all the things in iax.conf that would need a restart ?
By: James Golovich (jamesgolovich) 2004-03-08 18:03:07.000-0600

We should document all of these for now in the stable branch, and possibly later fix anything we can fix.  Some of these are too big of issues to deal with before 1.0 comes out
By: khb (khb) 2004-04-10 00:33:39

One example of these problems is the following:
To start, initially Asterisk is registered properly with iaxtel.com.  When issuing a "reload" command, asterisk will now try to reregister the connection, but instead of accessing iaxtel.com it will try registering with a host on my local network. This host is not an iax client at all, instead sometimes connects by SIP.  But even if the host is completely offline (powered down)  Asterisk will still try to register with it.  I could never figure out where it even got the IP address from.
Only terminating Asterisk and restarting cured the problem.

edited on: 04-09-04 23:26
By: Brian West (bkw918) 2004-04-10 06:51:17

I have seen this issue also... but it happens on SIP also.  anthm said my box was trying to register via sip to his box all day one day... then the next day it was trying to reg with IAX2 very weird issue.
By: Mark Spencer (markster) 2004-04-15 00:55:08

i don't see any way such a linkage can occur, can you duplicate and confirm this?
By: khb (khb) 2004-04-15 16:36:44

I saw it being discussed again today on the dev list.
By: khb (khb) 2004-04-16 16:31:50

Mark, when I observed this particular problem I didn't want to believe it either, I studied the code for hours and it made no sense to me how this could happen.
Since then, I have seen a couple of other strange problems which appear to share similarities with this, yet in different modules.
I now have the "feeling"  (how is that for precise programming logistics)  that these bugs have nothing directly to do with the IAX code.
For example I have seen SIP packets coming out of Asterisk that had the UserAgent identification string placed inside a SIP URI in a header  ie.   From: <Asterisk PBX@xxx.xxx.xxx.xxx>    NOW EXPLAIN THAT????!!!   The next morning I could not reproduce this with the identical setup.
These problems seem to have one thing in common, addresses to string storage or sockaddr_in's (in case of the IAX registration)  get somehow mixed up. This would point perhaps to a compiler/optimization problem and/or probably some memory managment issues. Any thoughts?

edited on: 04-16-04 15:47
By: Mark Spencer (markster) 2004-04-21 20:24:00

Wow, gethostbyname isn't reentrant.  Okay patch in CVS, tell me if that fixes things.
By: timecop (timecop) 2004-04-21 21:12:45

re: khb's bugnote and mark's fix.
Yes, it works (correctly) now.
There were a number of times before this fix (and none now) when I typed reload and iax would say something like "failed to register to 127.0.0.1".
another reload sometimes fixed it. Now this isn't happening. (no problem).
By: Mark Spencer (markster) 2004-04-21 23:36:24

Fixed in CVS