| Summary: | ASTERISK-16508: [patch] SIP autocreate peers disappear on "sip reload" | ||||
| Reporter: | Kirill Katsnelson (kkm) | Labels: | |||
| Date Opened: | 2010-08-04 20:50:43 | Date Closed: | 2012-01-31 18:15:31.000-0600 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Registration | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 017797-kkm-persist-autopeers-1.6.2.9.patch ( 1) 017797-kkm-persist-autopeers-1.8.patch | |||
| Description: | Upon reloading chan_sip configuration, all autocreated peers disappear. That's a big hassle if one runs an Asterisk server with 100s of autopeers (AI guys in our case) with some statically configured trunks that need a configuration change from time to time. Quoting lmadsen on the dev list: “I'm not sure if this is a bug or a feature :) Sounds like we might need an autocreatepeercache=[yes|no] option, in which case this would be a feature request.” The attached patch adds the third choice to the sip.conf global autocreatepeers= setting, "durable", to keep autopeers across config reload. The behavior of "yes" and "no" did not change. Attaching patch against the latest 1.8 trunk and another for those running 1.6, against 1.6.2.9 (we use the latter in production). ****** STEPS TO REPRODUCE ****** 1. Set autocreatepeers=yes 2. Register some autopeers 3. do CLI "sip reload". Automatically registered peers gone. ****** ADDITIONAL INFORMATION ****** Questions. 1. Is "durable" a good choice for the option name? Not sure if I like that myself... 2. The autocreatepeers= option is not documented. Should I add some documentation, or is it safer to leave it alone? | ||||
| Comments: | By: Leif Madsen (lmadsen) 2010-08-05 15:49:50 Documentation would be ideal. You should make sure you at least document what the option you're adding is providing. I'm not sure I like "durable". I think perhaps "persist" might be a better name as we've used that word in a few other places. Thanks for the patch! By: Leif Madsen (lmadsen) 2010-08-05 15:50:14 Marking as Confirmed as we have a patch, but it needs a bit of additional work before moving this up to Ready for Testing. By: Kirill Katsnelson (kkm) 2010-08-05 23:25:15 Done: changed option name; documentation added to 1.8 patch only. Please remove the 2 old patches uploaded on 2010-08-04 - thanks! By: Leif Madsen (lmadsen) 2010-08-06 14:05:38 Done! By: Leif Madsen (lmadsen) 2010-08-06 14:05:53 Updated to Ready for Testing. By: Jonathan Rose (jrose) 2011-12-23 11:19:17.974-0600 Testing this patch revealed one fairly minor flaw that I'm not really sure there is an easy (i.e. non-invasive) way around... When reloading with the mode being changed from persist to either yes or no, the peers will still persist. Likewise, if you change the mode from yes to persist, the peers in your peer list will still be deleted. This is because the marking of peers for deletion is done before the configuration file is read, so the previous configuration's settings apply for deleting the peers during the reload. By: Kirill Katsnelson (kkm) 2012-01-31 16:46:07.434-0600 Part flattery, part sad matter of fact: If jrose has no idea how to fix that, then we are in trouble. I think that having this feature, even with slightly inconsistent configuration reload behavior is much, much, incomparably better than not having it--in rare settings like the one here. And the rest would not care about changing it at all. Hey, it is not even currently documented! So all in all, I am all for committing this, even if on-the-fly changes are somewhat inconsistent. I'll explain the inconsistency in the documentation added with the patch. Good to go? By: Richard Mudgett (rmudgett) 2012-01-31 18:15:31.756-0600 Patch was committed to trunk on Dec 23, 2011 by jrose but the issue simply failed to get closed. | ||||