[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 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-08 01:04 CST
Last Modified:              2009-01-15 11: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...
====================================================================== 

---------------------------------------------------------------------- 
 (0097929) oej (manager) - 2009-01-15 11:05
 http://bugs.digium.com/view.php?id=14196#c97929 
---------------------------------------------------------------------- 
Realtime dynamic peers was designed not to be in memory, but be released as
soon as possible after registration or a call. Functions like qualify and
notifications require that peers are active in memory, thus should be
static, like the ones you configure in sip.conf.

Adding qualify or mailbox to realtime dynamic peers create a strange
hybrid that the SIP realtime architecture was never designed for and we now
have a big discrepancy after what people expect - the same functionality as
static peers and what it was designed for - dynamic peers.

I've asked for input on a redesign several times on the asterisk-dev
mailing list with no answers. I believe this is a growing issue, and will
all the patches to realtime dynamic peers (caching and stuff)  the
situation gets worse and worse and we are reaching a collapse... To be a
bit dramatic.

I think we have to make handling of static realtime peers easier. Load
from manager and cli, implement real caching so that we remove peers that
haven't been used for some time and don't have any requirements for staying
in memory and such stuff.

Long answer to a short question. Sorry. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-15 11:05 oej            Note Added: 0097929                          
======================================================================