[Home]

Summary:ASTERISK-05406: sip peers are not retained after restart
Reporter:radamson (radamson)Labels:
Date Opened:2005-10-31 14:33:17.000-0600Date Closed:2008-01-15 15:53:08.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
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:

[user]
type=friend
username=user
secret=secret
host=dynamic
canreinvite=no
qualify=yes
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:

/SIP/Registry/2001: 192.168.254.251:5061:600:2001:sip:2001@192.168.254.251:5061
/SIP/Registry/2002: 192.168.254.251:5062:600:2002:sip:2002@192.168.254.251:5062
/SIP/Registry/2006: 192.168.254.252:5060:3600:2006:sip:2006@192.168.254.252:5060
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:

/SIP/Registry/ext2006: 192.168.254.252:5060:3600:ext2006:sip:ext2006@192.168.254.252:5060
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

Repository: asterisk
Revision: 6916

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6916 | markster | 2008-01-15 15:53:07 -0600 (Tue, 15 Jan 2008) | 2 lines

Only consider timeouts on realtimers (bug ASTERISK-5406)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6916