[asterisk-dev] [Code Review]: Don't keep the STUN socket open between STUN monitor checks.
rmudgett
reviewboard at asterisk.org
Thu Dec 1 13:08:02 CST 2011
> On Dec. 1, 2011, 6:57 a.m., Simon Perreault wrote:
> > /branches/1.8/res/res_stun_monitor.c, line 331
> > <https://reviewboard.asterisk.org/r/1595/diff/6/?file=22038#file22038line331>
> >
> > stun_addr doesn't seem to be used after this call. So what is the purpose? There's already an ast_get_ip() call up above that is invoked every time the socket is refreshed, including I suppose on the first run, so I don't see what is this call's purpose.
This call is to give a sanity check to the configured STUN server address/name while the configuration is being loaded. A warning is issued indicating the offending configuration line and implying that the user can't spell or type worth a damn. :)
- rmudgett
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1595/#review4897
-----------------------------------------------------------
On Nov. 30, 2011, 6:35 p.m., rmudgett wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1595/
> -----------------------------------------------------------
>
> (Updated Nov. 30, 2011, 6:35 p.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> Re-resolve the STUN address if a STUN request poll fails.
>
> The STUN socket must remain open between polls or the external address
> seen by the STUN server is likely to change. However, if the STUN request
> poll fails then the STUN server address needs to be re-resolved and the
> STUN socket needs to be closed and reopened.
>
> * Re-resolve the STUN server address and create a new socket if the STUN
> request poll fails.
>
> * Fix ast_stun_request() return value consistency.
>
> * Fix ast_stun_request() to check the received packet for expected message
> type and transaction ID.
>
> * Fix ast_stun_request() to read packets until timeout or an associated
> response packet is found. The stun_purge_socket() hack is no longer
> required.
>
>
> This addresses bug ASTERISK-18327.
> https://issues.asterisk.org/jira/browse/ASTERISK-18327
>
>
> Diffs
> -----
>
> /branches/1.8/configs/res_stun_monitor.conf.sample 346655
> /branches/1.8/include/asterisk/stun.h 346655
> /branches/1.8/main/stun.c 346655
> /branches/1.8/res/res_stun_monitor.c 346655
>
> Diff: https://reviewboard.asterisk.org/r/1595/diff
>
>
> Testing
> -------
>
> * The STUN request still goes out periodically.
> * The STUN server DNS address is refreshed if the STUN request poll fails.
> * The received packets are read until there are none left or an associated packet is found.
>
>
> Thanks,
>
> rmudgett
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111201/cded217b/attachment.htm>
More information about the asterisk-dev
mailing list