[asterisk-dev] [Code Review] Don't keep the STUN socket open between STUN monitor checks.

mjordan reviewboard at asterisk.org
Wed Nov 23 10:52:12 CST 2011


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


Do we also need to update the CHANGES.txt, since this adds a parameter to the res_stun_monitor.conf file?


/branches/1.8/main/stun.c
<https://reviewboard.asterisk.org/r/1595/#comment9042>

    May want to change the documentation here to say that:
    <0 => error
    0 => success
    1 => timeout (or greater than 0)
    



/branches/1.8/res/res_stun_monitor.c
<https://reviewboard.asterisk.org/r/1595/#comment9043>

    May as well add the \internal tag on this guy as well



/branches/1.8/res/res_stun_monitor.c
<https://reviewboard.asterisk.org/r/1595/#comment9045>

    This function seems to do a bit more then parsing and setting up the address, since it also disables the STUN monitor, reenables it if it parses correctly, etc.
    
    If you want all this functionality in one method, I'd rename it to reflect all of its functionality



/branches/1.8/res/res_stun_monitor.c
<https://reviewboard.asterisk.org/r/1595/#comment9044>

    Should it?  That seems a bit odd - if I have in my config file:
    
    stunaddr =>
    
    I would expect that to be a configuration error, not a request to not have STUN monitoring.  At the very least, it seems that would make the "stunservermonitor" parameter redundant (also, if blank is acceptable but turns off STUN monitoring, that should be noted in the config file)


- mjordan


On Nov. 22, 2011, 6:43 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1595/
> -----------------------------------------------------------
> 
> (Updated Nov. 22, 2011, 6:43 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Don't keep the STUN socket open between STUN monitor checks.
> 
> Keeping the STUN socket always open will cause the STUN monitor to fail if 
> the STUN server address or our own address changes.  
> 
> * Fix the reverse problem of the STUN server address changing after the 
> initial DNS resolution by using the dnsmgr to refresh the DNS resolution.  
> However, refreshing the DNS resolution may not be desireable for all 
> cases, as a result the stunservermonitor option is added to enable this.  
> 
> * Fix ast_stun_request() return value consistency.
> 
> 
> This addresses bug ASTERISK-18327.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18327
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/stun.c 345978 
>   /branches/1.8/res/res_stun_monitor.c 345978 
>   /branches/1.8/configs/res_stun_monitor.conf.sample 345978 
> 
> Diff: https://reviewboard.asterisk.org/r/1595/diff
> 
> 
> Testing
> -------
> 
> The STUN request still goes out periodically.
> The STUN server DNS address is refreshed periodically if the new stunservermonitor option is enabled.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

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


More information about the asterisk-dev mailing list