[asterisk-dev] [Code Review] [18801] - features reload does not clear old configuration and always include 700 on parkedcalls : patch

[jrose]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1161/#review3290
-----------------------------------------------------------



/trunk/main/features.c
<https://reviewboard.asterisk.org/r/1161/#comment6862>

    This is NULL for the registrar because if [general] doesn't exist, asterisk is loaded, and then [general] is added, "parkedcalls" will lose the 'features' registrar and not be handled in the case where the features registrar is used.  It shouldn't make a difference since this is the only case where [parkedcalls] should really only exist if it's used as a parking lot.


- jrose


On 2011-04-06 10:50:38, jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1161/
> -----------------------------------------------------------
> 
> (Updated 2011-04-06 10:50:38)
> 
> 
> Review request for Asterisk Developers, David Vossel and rbyrant.
> 
> 
> Summary
> -------
> 
> This fix follows a completely different approach from the other one, so I created a new review request.
> This fix involves wiping all the parking lots in the parkinglots ao2_container while purging their extensions so that they have to be rebuilt when features reload is performed.
> 
> I have a bit more confidence in this one.  It's much more additive and much less destructive than the last one.
> 
> 
> This addresses bug 18801.
>     https://issues.asterisk.org/view.php?id=18801
> 
> 
> Diffs
> -----
> 
>   /trunk/main/features.c 312991 
> 
> Diff: https://reviewboard.asterisk.org/r/1161/diff
> 
> 
> Testing
> -------
> 
> Tested with multiple parking lots, changing multiple parking lots, with and without [general], with general and then without general and then with general again (which showed a need for an additional change), and mixes of all the above.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110406/ab912c19/attachment.htm>