<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/1595/">https://reviewboard.asterisk.org/r/1595/</a>
     </td>
    </tr>
   </table>
   <br />





 <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">One last bit of advice: when you reopen a new socket for each STUN request, you will end up using different source ports. Some NATs using a pool of public IP addresses will assign a different external source IP to flows originating from different internal source ports, even if they originate from the same internal source address. With this patch, stun_res_monitor becomes unusable behind those NATs.

Overall, I dislike this patch. This is not how STUN was intended to be used. I described a number of problems, and I would not be surprised if more were discovered later.</pre>
 <br />







<p>- Simon</p>


<br />
<p>On November 29th, 2011, 7:17 p.m., rmudgett wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By rmudgett.</div>


<p style="color: grey;"><i>Updated Nov. 29, 2011, 7:17 p.m.</i></p>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Don&#39;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.
</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The STUN request still goes out periodically.
The STUN server DNS address is refreshed if the STUN poll fails.</pre>
  </td>
 </tr>
</table>



<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>


 <a href="https://issues.asterisk.org/jira/browse/ASTERISK-18327">ASTERISK-18327</a>


</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>/branches/1.8/configs/res_stun_monitor.conf.sample <span style="color: grey">(346465)</span></li>

 <li>/branches/1.8/include/asterisk/stun.h <span style="color: grey">(346465)</span></li>

 <li>/branches/1.8/main/stun.c <span style="color: grey">(346465)</span></li>

 <li>/branches/1.8/res/res_stun_monitor.c <span style="color: grey">(346465)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/1595/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>