Summary:	ASTERISK-23789: [patch] - Registry counter badly dec. with Realtime
Reporter:	Dr Lous (drlous)	Labels:
Date Opened:	2014-05-26 13:47:05	Date Closed:	2017-12-14 16:44:53.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/Registration
Versions:	12.2.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	One sip registration, full Realtime.	Attachments:	( 0) patch_chan_sip_regobjs_counter_12.2.0.txt ( 1) patch_chan_sip_regobjs_counter_12.2.0.txt ( 2) sip_reload_no_register.txt
Description:	If you use Realtime for sippeers, the chan_sip.c get peers available for registry (eq. to "register=>" in sip.conf). But when parse different row in the database, sip_register structure built everytime and check the regl object if already added. If already added the object is destroy. But every destroy decrement the registry object counter. Tested version 12.2.0 Result of this bug : you start asterisk => every fine good, registry made to ISP (in this case) and call is ok. But if you make "sip reload" the regobjs counter go negative and no register made and all stay Unregistered for ever.
Comments:	By: Dr Lous (drlous) 2014-05-26 13:49:24.189-0500 Modify the sip_register struct to add flag when this object is added into main chan_sip.c array for delete only already added By: Matt Jordan (mjordan) 2014-05-26 14:59:01.429-0500 I don't understand the bug here. {{chan_sip}} does not support realtime storage of outbound registrations. You've made an issue and a patch to do that in ASTERISK-23787 - which is great - but any off nominal behaviour introduced as a side effect of that patch is not a bug in Asterisk. Based on your description, it sounds as if there is a bug in your patch that should be fixed in ASTERISK-23787. By: Dr Lous (drlous) 2014-05-26 15:18:13.132-0500 No, this is different. Same bug with no patch for update proxy sip. On realtime config, every object created for registration (3 times when only single object in db => 3 different request to DB), make new sip_register object and increment the refcounter. When refcounter go 0, the sip_registry_destroy called => decrement the regobjs counter. But when db search find object (peer) already in the registry array, the destroy decrement counter, but is not incremented before. I don't know if I'm clear about this issue ? By: Dr Lous (drlous) 2014-05-26 15:32:51.178-0500 Attach file, debug output when sip reload. Before reload, regobjs is already -1 ! On start of asterisk => 2x "Destroying registry entry", so 2x "regobjs--", but only one added to registry array. After sip reload, one destroy only, because flush registration array. And the computation of delay for the sched, make negative value (regobjs == -2, default_expiry == 120, so ms = -12000) I recompiled from tarball 12.2.0, bug/issue is on original source, not after my other patch. By: Dr Lous (drlous) 2014-05-26 15:34:33.618-0500 Patch for solution (first submission is deleted) By: Matt Jordan (mjordan) 2014-05-27 08:48:55.153-0500 Looking at your patch, I can see how we would incorrectly calculate the total number of {{sip_registry}} objects. If the {{sip_registry}} object has already been linked in the container, we will decrement the {{regobjs}} counter even though we did not increment it, as we only increment on a successful linking. It would be nice if the {{ASTOBJ}} usage was replaced with {{ao2}} containers in the future, but this does address this particular bug. By: Corey Farrell (coreyfarrell) 2017-10-18 14:24:34.551-0500 Since your post all usage of ASTOBJ has been replaced by ao2.  Can you check if this is still an issue with a recent release of Asterisk 13 or 15? By: Corey Farrell (coreyfarrell) 2017-12-14 16:44:53.872-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines \[1\]. \[1\] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines