Summary:	ASTERISK-08836: Realtime change of host in iaxpeers does not force a change in the peers without reload
Reporter:	Tony Plack (plack)	Labels:
Date Opened:	2007-02-18 23:40:55.000-0600	Date Closed:	2011-06-07 14:08:16
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	If a peer is set up with a host entry like: name1.host.com and the host is used at least once, when/if a change is made to that host in the iaxpeers table to: name2.host.com and a call is placed, the system still tries to use the IP of name1.host.com. The peer IP address does not change and there seems to be no check of the system for this new host name in the table. ****** ADDITIONAL INFORMATION ****** This seems to corrolate with Issue 0009097 which I reported. It seems that if the IP address of a peer is set, there is no reference back to the *dnsmgr structure in the code to verify that the host has not changed. This might be a performance drain on the server to do the lookup, so I am not sure how it should be solved.  With issue 0009097, this problem makes changing a host in realtime next to imposible.
Comments:	By: Joshua C. Colp (jcolp) 2007-02-19 08:05:28.000-0600 Are you using realtime caching? By: Tony Plack (plack) 2007-02-19 11:30:04.000-0600 Thought about that this morning... rtcachefriends=yes rtcupdate=yes rtautoclear=no rtignoreregexpire=yes I notice in channels/chan_iax2.c on line 2564: ast_update_realtime("iaxpeers", "name", peername, "ipaddr", ast_inet_ntoa(sin->sin_addr), "port", port, "regseconds", regseconds, NULL); This code is in realtime_update_peer subroutine and while it updates the ipaddr, it does not update the host. This code is called during expire_registry but only if rtupdate=yes and rtcachefriends=yes.  Both of these are set in my iax.conf, so it is calling this routine, but the routine makes no reference to the host, just &p->addr. Hope that helps.... I believe what must happen is that for realtime_update_peer, we need to pass the entire peer structure and then parse the pieces we need to check for updates, including the host name. addr means nothing if you are using host name. By: Joshua C. Colp (jcolp) 2007-02-19 11:33:08.000-0600 Caching implies that all information will be pulled from memory. It does not check the database at all since that would just negate what caching is all about. If you would like to expand capability to add an option for a blended capability (if that even makes sense... I'm of the opinion it doesn't) then feel free to. By: Tony Plack (plack) 2007-02-19 13:14:45.000-0600 My understanding was that caching was not to eliminate the benifits of "realtime" involvement, but to correct the assumption that realtime was for momentary connections.  The main goal was to allow MWI on realtime phones. Regardless, the code does not support that assumption as well when you use host instead of ipaddr.  It updates for ipaddr but not for host. The subroutine "realtime_update_peer" updates the cache values from the database.  This subroutine in "chan_iax.c" is called on the "registry_expiration" and on the "update_registry" subroutine as well. It is my understanding that the update to the registry from the database is regular and consistant and the rccachefriends and rtupdate flags control if you want to do this or not.  I understand this from the code so I don't think it is a philisophical question or feature addition. The problem is that it is updating for IP address but not for host name. The correct behavior is if you want to use host name, update the hostname as well. Please help me adjust my understanding if I am not correct or if "rtcupdate" is deprecated and being removed from the trunk. Thanx. By: Joshua C. Colp (jcolp) 2007-02-19 13:18:34.000-0600 It is for dynamic peers that register to Asterisk. If rtupdate is set to yes, their new registered IP address is updated in the database. By: Tony Plack (plack) 2007-02-19 13:44:04.000-0600 Thank you, I was looking at it incorrectly.  I was seeing it as reading rather than updating.  My bad. Would be nice if it re-read the values, but I understand now. By: Joshua C. Colp (jcolp) 2007-02-20 09:09:26.000-0600 Okay since this isn't a bug but was just a misunderstanding... closing this out.