Summary:	ASTERISK-03544: SIP User permanently bound to IP
Reporter:	ron anderson (ron anderson)	Labels:
Date Opened:	2005-02-18 16:56:23.000-0600	Date Closed:	2011-06-07 14:10:08
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) SIP_IP_not_updating.txt ( 1) SIP_IP_problem ( 2) xten_log.txt
Description:	I move my development Asterisk box between two different private networks.  One with 192.168.143.XXX IP's and the other with 192.168.1.XXX IP's.  I recently upgraded to CVS HEAD to set up and test Realtime and have discovered upon moving my box from the 192.168.143.XXX network to the 192.168.1.XXX network that the IP address associated with my SIP softphone (Xten) user in Asterisk is always the IP it used to first register (the 192.168.143.XXX number). See additional info on what I've attempted to resolve. ****** ADDITIONAL INFORMATION ****** I reverted to original sip.conf but Asterisk continues to try and use the old 192.168.143.221 address to connect to user.  I then added a new SIP user [2102] with all the same info and changed the xten client and it worked. I've upgraded to the lastest CVS HEAD and reinstalled everything and the issue is still here.  I've also deleted and re-added the record in sipfriends with complete system restarts. I've attached the debug info from the console showing the two calls, [2101] continues to be bound to the 192.168.143.221 IP no matter what I seem to do.   Nothing I do seems to get the IP to update to the new one (192.168.1.104 in this case). I have Realtime voicemail and MySQL cdr working perfectly but extensions is still using .conf.
Comments:	By: Olle Johansson (oej) 2005-02-19 03:58:04.000-0600 I guess the old IP adress is coming from astdb on your "mobile Asterisk" server. Do a "show database" on the CLI to see the SIP entries for your client. When the softphone registers, it will update with a new IP adress. If you can't see the IP adress in the astdb, there's another problem. Make the client register and see what happens. Guess we could have an option saying "don't save in astdb", but I can't see that as a bug, more of a feature request. If you make Xten unregister at exit (which is the default if you actually exit Xten) and then restart it to make it register again, you propably will not have a problem. The simple solution is to run a script that removes the db entry (asterisk -x "database delete yyy/xxx" then restart Asterisk. Please confirm that it works for you. By: Mark Spencer (markster) 2005-02-19 10:26:25.000-0600 Where's the debug of the new register request? By: Olle Johansson (oej) 2005-02-20 00:52:56.000-0600 Ron, Any comments? By: ron anderson (ron anderson) 2005-02-23 17:55:56.000-0600 I've tried your suggestion to delete the database key which worked.  The method I've used to recreate it is by getting a xten client fired up with a new DHCP'd IP address (192.168.1.107) and setting it up to use with the 2101 extension. As you can see in the attached debug, the SIP xten client can't register even though I've updated the sipfriends table with the new .107 IP address and when I place a call from zap extension 100 the call fails as it is trying to seed to the old .106 IP address. Once I did a 'database del SIP Register/2101' and tried making a call from a zap phone to that SIP client (2101) it worked and sipfriends was updated as expected with the new .107 IP address. One thing that may be affecting this is my use of "defaultip" in sipfriends.  Seems like it shouldn't affect updating the db.  The new attached file shows the sip debug info.  Also will update the xten client log. By: Olle Johansson (oej) 2005-02-25 07:11:21.000-0600 OK, will take a look at this. THank you for the information, maybe you're right that there's something wrong with the defaultip setting. By: ron anderson (ron anderson) 2005-02-28 14:12:41.000-0600 This does only seem to be an issue with defaultip as when I remove it, the clients register with new ip's and everything works as it should.  My original problem with the client not being able to register which was forcing me to use defaultip turned out to be a simple firewall blocking problem in IPTABLES. Should this be closed since its not causing any issues for me? By: Olle Johansson (oej) 2005-03-16 13:23:14.000-0600 No more problems, no coding changes needed. Defaultip and realtime may not be a good thing, maybe we need to look into that.