[asterisk-bugs] [Asterisk 0014196]: [patch] Realtime peers are never qualified after 'sip reload'

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14196 
====================================================================== 
Reported By:                pdf
Assigned To:                blitzrage
====================================================================== 
Project:                    Asterisk
Issue ID:                   14196
Category:                   Channels/chan_sip/DatabaseSupport
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     confirmed
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 167620 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-08 01:04 CST
Last Modified:              2009-01-14 09:49 CST
====================================================================== 
Summary:                    [patch] Realtime peers are never qualified after
'sip reload'
Description: 
Realtime SIP peers all report status as 'UNKNOWN' when re-initialised after
'sip reload'.  Peers are never sent OPTIONS qualify packet after reload,
unless they re-register.



    -- Registered SIP 'nnn' at xxx.xxx.xxx.xxx port 5060
pabx*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status    
Realtime  
nnn/nnn                    xxx.xxx.xxx.xxx       D          5060     OK
(35 ms) Cached RT 
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0
offline]


pabx*CLI> sip reload
 Reloading SIP
  == Parsing '/etc/asterisk/sip.conf': Found
  == Parsing '/etc/asterisk/users.conf': Found
  == Parsing '/etc/asterisk/sip_notify.conf': Found
pabx*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status    
Realtime  
nnn/nnn                    xxx.xxx.xxx.xxx       D          5060    
UNKNOWN    Cached RT 
1 sip peers [Monitored: 0 online, 1 offline Unmonitored: 0 online, 0
offline]



======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013316 Realtime registrations don't work after...
====================================================================== 

---------------------------------------------------------------------- 
 (0097725) pdf (reporter) - 2009-01-14 09:49
 http://bugs.digium.com/view.php?id=14196#c97725 
---------------------------------------------------------------------- 
OK, looks like this bug goes back a while.  In the mean time, I see the
problem with Corydon76's patch - missing a key on the ast_update_realtime. 
With the update keyed by "name", results do get into the DB.  However, this
code is only hit at register time, so devices will now work properly until
they re-register.  If I put an update_peer in the handle_response_peerpoke,
like so:

--- channels/chan_sip.c.dist    2009-01-15 00:46:12.197536110 +1100
+++ channels/chan_sip.c 2009-01-15 02:21:06.906785966 +1100
@@ -12739,6 +12739,8 @@
                ASTOBJ_UNREF(peer_ptr, sip_destroy_peer);
        }
 
+       update_peer(peer, ast_sched_when(sched, peer->expire));
+
        ast_set_flag(&p->flags[0], SIP_NEEDDESTROY);
 
        /* Try again eventually */

Things start to work nicely, in fact it seems to fix a number of
situations, ie - peers get populated properly when they place an inbound
call, as well as when an outbound call is placed, and when the peer is
explicitly loaded after a 'sip reload'.

Obviously it's not the most efficient option as I'm updating the whole
peer every qualify, so I'm open to suggestions... attaching the updated
patch with the fix for Corydon76's code, and the diff in this comment.


PS - I can't seem to reproduce the OPTIONS flood now, but there may be
some combination of sip.conf settings that will produce it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-14 09:49 pdf            Note Added: 0097725                          
======================================================================