Summary:	ASTERISK-06591: Reload/Restart clears sip peer information with Realtime
Reporter:	Douglas Garstang (dgarstang)	Labels:
Date Opened:	2006-03-21 12:39:07.000-0600	Date Closed:	2011-06-07 14:03:07
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/DatabaseSupport
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I have this in sip.conf: rtcachefriends=yes rtupdate=yes rtautoclear=yes and this in extconfig.conf: sipusers => mysql,vox180internal,ast_sip_users sippeers => mysql,vox180internal,ast_sip_users I have a fully popular astdb file. When asterisk starts up, with no users in sip.conf, but provisioned in the ast_sip_users table, the output of 'sip show peers' remains empty until each user registers. When I do a 'reload' or restart Asterisk, the list from 'sip show peers' is cleared again. When users are provisioned in sip.conf, the output of 'sip show peers' upon immediate start of Asterisk is fully populated, presuambly from the astdb file. Why does this behaviour change for users provisioned in sip.conf and in sip realtime? This is a MAJOR problem. If you restart asterisk or issue a 'reload' command, you lose all peer information. I had always assumed that the MWI functionality in Asterisk was based off data in the astdb file, but it must first be referencing the peer list, because when this list is cleared, eventhough all the entries in astdb remain, MWI stops working. This is an absolute deal breaker. We can't lose all mwi functionality every time we issue a reload command or restart Asterisk. Whether you use realtime or not, the 'sip show peers' information should be populated from astdb upon start of Asterisk.
Comments:	By: Russell Bryant (russell) 2006-03-21 13:45:27.000-0600 The "sip show peers" output has *nothing* to do with anything that is in astdb. "sip show peers" simply traverses the internal list of peers and shows you information about them.  When using realtime, the only peers that will be seen are the ones currently cached.  Also, when you issue a reload, the cache is cleared.  This is what causes you to lose MWI. However, there should be no reason you should need to issue a reload of chan_sip during any kind of regular operation.  Therefore, I don't really think this is a problem. By: Russell Bryant (russell) 2006-03-21 13:49:40.000-0600 Please be more careful when filing bug reports.  This obviously has nothing to do with gastman. By: Douglas Garstang (dgarstang) 2006-03-21 14:32:16.000-0600 Well what do you suggest I file it under? I don't see a app_sip in the list or anything related to Realtime. Cached from what? Cached from astdb or cached from the database? Why does realtime only store peers that are cached? Why is the operation different from using the flat text files for configuration? You don't lose the cache when you do a reload when using flat text files. Why is realtime different? Have you people ever heard of HIGHLY AVAILABLE configurations? It doesn't matter if a reload is part of normal operations or not. The point is that it COULD happen. What if you have several dozen or several hundred phones registered on this system and have to issue a reload for some reason? Suddenly none of the phones will get MWI until they all re-register. This is a SERIOUS limitation and is not acceptable. By: twisted (twisted) 2006-03-21 14:46:43.000-0600 This is a community project, and is open source.  Demanding things from the maintainers is not going to get you anywhere.   Feel free to contribute code to the project, pay someone to solve this as you see fit, or ask nicely, and someone may help you solve the problem.   This software is free, and nobody deserves to be barked at the way you are currently doing.   Thanks! By: Douglas Garstang (dgarstang) 2006-03-21 14:48:05.000-0600 I'm not making demands. I'm asking perfectly valid questions. By: twisted (twisted) 2006-03-21 14:51:02.000-0600 I agree, however, reading that previous note seemed a bit demanding and demeaning.   The answer to your question is this: Realtime currently operates under the assumption that reloading/restarting is not necessary since everything that can be changed in a realtime configuration is done on-the-fly and checked for/loaded as needed.  The caching option is so that once it's loaded, it's in memory until that memory is flushed.   If you would like to see an option to keep realtime peers/users loaded in memory or astdb through a reload/restart, feel free to follow the options I mentioned above to get that code created and/or commited to the project. By: Andrew Kohlsmith (akohlsmith) 2006-03-21 14:53:11.000-0600 dgarstang, please read your own posts before writing such crap. Both "Have you people ever heard of HIGHLY AVAILABLE configurations?" and "This is a SERIOUS limitation and is not acceptable." are using a very agressive tone of voice and your posts come off as very confrontational. Again -- this is an open-source project.  You've paid nothing for this software.  If you find the software's behaviour so unacceptable and can't accept the pace that it is being addressed, I suggest you either fix it yourself, hire someone to make it their problem, or find another project.  We appreciate these issues being brought to light and among other things, this will get fixed in time but standing over our shoulders making these kinds of demands is something we will simply not accept. By: Douglas Garstang (dgarstang) 2006-03-21 14:56:45.000-0600 I think making the assumption that reloads/restarts are not necessary is a bad assumption to make. Unfortunately we can't afford the time to wait for such a fix to be implemented, and I'm not a C programmer. I'll just have to go back to using the flat files for sip user configuration, and deal with the nightmare that will ensue provisioning it over five Asterisk servers. By: Jason Parker (jparker) 2006-03-21 14:58:54.000-0600 The other option is to pay for the development of a patch. By: Russell Bryant (russell) 2006-03-21 15:21:26.000-0600 Try the attached patch.  However, if it doesn't work correctly on my first try, hopefully it won't be too much of a SERIOUS issue and not acceptable. By: Russell Bryant (russell) 2006-03-21 15:30:58.000-0600 I have deleted the patch because I'm not ready to release it. By: Olle Johansson (oej) 2006-03-22 01:43:08.000-0600 dgarstang: The SIP channel has two kinds of objects, static and dynamic. The static objects are loaded from sip.conf in a text file or trough the realtime engine. These are loaded in memory at each start or reload of the sip channel. They do not persist in memory during reloads, unless they are registered. It may look so, but what you see are actually new objects created from the new configuration. For peers, we reload some data from astdb in this case to keep them alive. The dynamic objects are never loaded in memory at reload, and are cleared from memory at reload. As soon as they perform an action, like a registration or a call, they are looked up and handled. If caching is turned on, we keep them in memory during the registration, otherwise we forget everything about them. This is the intended architecture. This is not a difference between realtime or not realtime, it's two different types of peers you are discussing and the behaviour for these are different and should be. That we remove the cached peers only mean, as you point out, that they won't have any mwi until next registration. If you don't like that, then load them as static peers or shorten the registration interval. Since this is not considered a bug, but a support issue until we agree that it is a bug somewhere, this discussion is moved from the bug tracker back to the mailing lists. Thank you all.