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

rmudgett reviewboard at asterisk.org
Wed Nov 30 18:35:35 CST 2011

This is an automatically generated e-mail. To reply, visit:

(Updated Nov. 30, 2011, 6:35 p.m.)

Review request for Asterisk Developers.


Addressed Simon's last comment and also an earlier suggestion.

* The STUN socket now remains open until a poll fails.
* The resolved STUN address is no longer kept once the socket is opened.
* The STUN code now checks the transaction ID and the message type for matches.  The STUN socket flush hack is no longer required.  (The STUN packet handling code is still terrible.)

Summary (updated)

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

This addresses bug ASTERISK-18327.

Diffs (updated)

  /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 (updated)

* 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111201/4e577b54/attachment-0001.htm>

More information about the asterisk-dev mailing list