[asterisk-dev] [Code Review] chan_sip: Address reload problems against registry introduced by autocreatepeer persist option changes

[jrose]

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



/branches/11/configs/sip.conf.sample
<https://reviewboard.asterisk.org/r/2171/#comment14130>

    change 'any UAC not explicitly defined in sip.conf to just 'any UAC not explicitly defined'.
    
    In retrospect the original statement omits realtime peers and such as well. I'm just trying to clean up some of the ambiguity here of course.


- jrose


On Oct. 30, 2012, 1:18 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2171/
> -----------------------------------------------------------
> 
> (Updated Oct. 30, 2012, 1:18 p.m.)
> 
> 
> Review request for Asterisk Developers and Matt Jordan.
> 
> 
> Summary
> -------
> 
> While working on a patch submitted by Kirill Katsnelson, I failed to notice that I introduced a somewhat breaking change against SIP reloads where the registry would be pruned and couldn't be brought back without either restarting Asterisk or fully unloading and reloading the chan_sip module. The problem occured when I moved the peer destruction marker callback to below the general section, at the time not having considered that peers could be created within the general section.
> 
> 
> This addresses bug ASTERISK-20611.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20611
> 
> 
> Diffs
> -----
> 
>   /branches/11/channels/chan_sip.c 375482 
>   /branches/11/configs/sip.conf.sample 375482 
> 
> Diff: https://reviewboard.asterisk.org/r/2171/diff
> 
> 
> Testing
> -------
> 
> Tested that the various autocreatepeer options still work.
> Tested that registry loads and reloads as expected.
> 
> 
> Thanks,
> 
> jrose
> 
>

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