Summary:	ASTERISK-16659: sip peer isnt freed
Reporter:	Marek Cervenka (cervajs)	Labels:
Date Opened:	2010-09-08 08:37:57	Date Closed:	2011-06-07 14:10:47
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) console.txt ( 1) sip.conf ( 2) siptrace.txt
Description:	sip peer isnt freed after change to something else i have peer newtravel with ip X.X.X.X then i change it to newtravel2 with the same ip but when i call, asterisk says that he found peer "newtravel" i will check tonight if it is reproducible on other 1.6.2.11  asterisk machine ****** ADDITIONAL INFORMATION ****** call from sip trunk newtravel2 with ip X.X.X.X Sending to X.X.X.X : 5060 (NAT) Using INVITE request as basis request - 16635cab0b9cc4905dd9cd9a690f44ba@X.X.X.X Found peer 'newtravel' for '123456789' from X.X.X.X:5060 v*CLI> sip show peers like newtravel Name/username              Host            Dyn Nat ACL Port     Status     0 sip peers [Monitored: 0 online, 0 offline Unmonitored: 0 online, 0 offline]
Comments:	By: Leif Madsen (lmadsen) 2010-09-08 12:00:46 You will have to provide a SIP trace, console output, and your sip.conf configuration file. I suspect you may need to unload the chan_sip.so module and then load it (not just a reload). Alternatively you may need to remove entries out of the AstDB using the 'database' CLI command from Asterisk. By: Marek Cervenka (cervajs) 2010-09-09 06:26:42 there arent any entries with "newtravel" in AstDB. after asterisk restart sip trunk works. i will try setup test system on friday and post sip trace .. By: Marek Cervenka (cervajs) 2010-09-10 10:42:21 I acknowledge that this problem is reproducible By: Marek Cervenka (cervajs) 2010-09-10 10:46:42 howto reproduce create sip peer i.e. test1 (host=ip not dynamic. sip trunk) reload call is ok modify sip peer username to test2 reload you will see [Sep 10 17:41:44] WARNING[27975]: chan_sip.c:12738 check_auth: username mismatch, have <test1>, digest has <test2> [Sep 10 17:41:44] NOTICE[27975]: chan_sip.c:20082 handle_request_invite: Failed to authenticate device "300" <sip:300@x.x.x.x>;tag=as68a85759 By: Stefan Schmidt (schmidts) 2010-09-12 15:32:00 how do you test this? with a phone or another asterisk? i think the dialog (tag and call-id) would match to the old peer cause they are linked and not changed by a sip reload. what happens if you reboot your phone after the reload, will the call work? anothter thing could be the ao2 container for peers. could you paste the output of sip show objects before you do the reload and also after. i am interested if it would have the same link id (which could be possible) By: Marek Cervenka (cervajs) 2010-09-13 08:15:26 it's asterisk1 to asterisk2 (no registration, host=ip and auth) asterisk1 restarted made call from asterisk2 (ok) sip show objects name: blumenfeld4 type: peer objflags: 0 refcount: 3 changed sip name to blumenfeld5 sip reload sip show objects name: blumenfeld5 type: peer objflags: 0 refcount: 3 Sep 13 15:13:28] WARNING[16084]: chan_sip.c:12738 check_auth: username mismatch, have <blumenfeld4>, digest has <blumenfeld5> sip show objects name: blumenfeld5 type: peer objflags: 0 refcount: 3 schmidts: it's test box. if you want ssh acces to asterisk1 it's possible (cervajs@freevoice.cz) By: Leif Madsen (lmadsen) 2010-09-13 10:59:00 cervajs: it's probably easier for you to produce the information as requested. If a developer wishes to login that's fine, but I tend to see that not happening very often. What if you completely unload chan_sip.so and then load it again? I suggested that earlier, but didn't get any information stating whether that helped or not. By: Marek Cervenka (cervajs) 2010-09-13 13:18:51 lmadsen: sorry :( module unload chan_sip.so module load chan_sip.so after module unload/load it's ok By: Marek Cervenka (cervajs) 2010-09-21 08:12:31 it's solved in 1.6.2.13 i dont know in which revision :( By: Brett Bryant (bbryant) 2010-09-21 12:10:19 Closing this issue since you're no longer reproducing this bug with a newer version of 1.6.