[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 03:05 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0097707) pdf (reporter) - 2009-01-14 03:05
 http://bugs.digium.com/view.php?id=14196#c97707 
---------------------------------------------------------------------- 
Nope, it's beyond me without spending much more time in the chan_sip code -
I can get the qualify to work when the peer is alive, but once the peer
goes away (after `sip reload`), the poke_peer goes into a spiral and floods
the device off the network with OPTIONS.  Obviously the sched is not
destroyed when the peer is removed from memory - I tried achieving this
with a different approach subsequent to my previous (incorrect) patch, but
was unsuccessful.

This is with 'rtcachefriends=yes', without which, I actually get _0_ peers
loaded into memory from realtime, ever.  Not only do the peers not show up
with rtcachefriends=no, I get the OPTIONS spiral of death mentioned above,
on vanilla 1.4.22, for every peer that registers - which hammers the phone,
throttles the network, and flogs Asterisk.

So, the two major problems:

1. Realtime peers are not loaded into memory when loading or reloading
chan_sip (and never at all without rtcachefriends).
2. sip_poke_peer is only activated for realtime peers when registering
using rtcachefriends=yes, not at restart or reload.  With
rtcachefriends=no, it is the same, except that the peer is _never_ loaded
into memory, so sip_poke_peer is called recursively until it floods the
phone off network.

These are serious regressions, and unfortunately not only does the first
need addressing, but Corydon76's patch doesn't resolve the second here
either.  So, any ideas on where we go from here?  This is hurting a number
of our clients, and whilst I'd prefer not to have to revert back to
1.4.21.x, I'm going to have to do so immediately.  I'm happy to keep
testing with you guys to resolve this though, once I'm done reverting
things. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-14 03:05 pdf            Note Added: 0097707                          
======================================================================