|Summary:||ASTERISK-05406: sip peers are not retained after restart|
|Date Opened:||2005-10-31 14:33:17.000-0600||Date Closed:||2008-01-15 15:53:08.000-0600|
|Environment:||Attachments:||( 0) db_restart.txt|
( 1) restart.txt
( 2) sip_friend.txt
( 3) sip_reg_subs.txt
|Description:||Executing a 'stop now' followed by an asterisk start does not retain the sip peers. Same with 'restart now'. Calls cannot be placed to any sip phone until after the next time the phone registers (in many cases, 3600 seconds).|
Problem just appeared in the last several days in cvs-head.
****** ADDITIONAL INFORMATION ******
Possibly related to some cvs-head changes completed by Mark between Oct 26th and Oct 30th.
|Comments:||By: Kevin P. Fleming (kpfleming) 2005-10-31 16:05:43.000-0600|
Well, I cannot reproduce this problem... I set up a new Asterisk instance with a single SIP peer, and registered a Polycom 601 to that SIP peer. During the registration, the Asterisk database was properly updated with the contact information, and it was reloaded (seeded) during restart.
After restart, 'sip show peers' shows the expected information, and qualify packets are successfully being sent and replied to.
By: mike9 (mike9) 2005-10-31 16:45:59.000-0600
I can verify the problem on an Asterisk build from this morning... (Friday morn build did not have this problem) Asterisk CVS HEAD i686 running Linux on 2005-10-31 13:09:58 UTC
relavent sip.conf settings:
By: Kevin P. Fleming (kpfleming) 2005-10-31 16:49:58.000-0600
I still cannot reproduce this... can you provide the output of 'database show SIP' _before_ the phones re-register themselves?
By: kuj (kuj) 2005-10-31 16:51:53.000-0600
Well, I can reproduce the problem, with a cvs Head build from just 5 minutes ago. Start *, then restart my SIP peers (Polycom IP500, or PAP2). They are there:
ext2006/ext2006 192.168.254.252 D 5060 OK (137 ms)
ext2002/ext2002 192.168.254.251 D 5062 OK (55 ms)
ext2001/ext2001 192.168.254.251 D 5061 OK (34 ms)
"restart now", without rebooting the peers, and they are gone:
ext2006 (Unspecified) D 0 UNKNOWN
ext2002 (Unspecified) D 0 UNKNOWN
ext2001 (Unspecified) D 0 UNKNOWN
The database registration info is there before and after the restart:
By: Kevin P. Fleming (kpfleming) 2005-10-31 16:56:14.000-0600
Aha... now I see it. The peer name in the SIP/Registry key is wrong, it's 2001 when it's supposed to be ext2001. Will fix, stay tuned...
By: kuj (kuj) 2005-10-31 16:58:35.000-0600
Went back to a previous build I had still around (Oct. 12, or so) and it behaves normally. Registrations will "survive" a restart. If this is related to chan_sip.c, the old, working version is 1.882.
By: kuj (kuj) 2005-10-31 17:02:09.000-0600
And yes, kpfleming, you're on the right track there. The old, working version has registration info like this:
By: Kevin P. Fleming (kpfleming) 2005-10-31 17:04:07.000-0600
Hmm.. I still cannot reproduce this problem. Can you show me a snippet of your sip.conf for these peers and a REGISTER packet coming in from one of them? Thanks.
By: Kevin P. Fleming (kpfleming) 2005-10-31 17:11:49.000-0600
OK, here is the ideal scenario:
1) Start Asterisk with the SIP peers turned off.
2) 'database deltree SIP' to clear out the database.
3) Turn the SIP peers back on and let them register.
4) 'database show SIP' and post the output (ideally with the matching REGISTER requests).
5) Turn the SIP peers back off, 'restart now'.
6) 'database show SIP' again.
By: kuj (kuj) 2005-10-31 17:37:57.000-0600
The attached sip_reg_subs trace is a sip debug starting right after when * determined the peer is unreachable to when registration (and buddy status subscription) succeeded.
By: kuj (kuj) 2005-10-31 17:42:14.000-0600
And the restart sequence shows that the database entry gets wiped. (?)
By: Kevin P. Fleming (kpfleming) 2005-10-31 17:48:14.000-0600
OK, but what is important is to know what was in the database before the restart... 'sip show peers' does not show that, it shows what is in memory. If you can redo the test ensuring that the database is _empty_ before registering the peer, and then doing 'database show SIP' after the peer has registered but before restarting, then we will know at what point the database entry is being created improperly.
By: kuj (kuj) 2005-10-31 18:06:32.000-0600
See db_restart.txt. It does get wiped, presumably upon starting up?
By: Kevin P. Fleming (kpfleming) 2005-10-31 18:10:17.000-0600
Yes, that does appear to be the case. At this point we will need to get remote access to a system having this problem so we can work through it... If you can provide such, please find me on IRC.
By: Mark Spencer (markster) 2005-10-31 18:47:08.000-0600
Fixed in CVS head,
By: Digium Subversion (svnbot) 2008-01-15 15:53:08.000-0600
r6916 | markster | 2008-01-15 15:53:07 -0600 (Tue, 15 Jan 2008) | 2 lines
Only consider timeouts on realtimers (bug ASTERISK-5406)