<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 />








<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On November 24th, 2011, 7:20 a.m., <b>Simon Perreault</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
 <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
    <a href="https://reviewboard.asterisk.org/r/1595/diff/3/?file=21848#file21848line56" style="color: black; font-weight: bold; text-decoration: underline;">/branches/1.8/res/res_stun_monitor.c</a>
    <span style="font-weight: normal;">

     (Diff revision 3)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">ASTERISK_FILE_VERSION(__FILE__, &quot;$Revision$&quot;)</pre></td>

  </tr>
 </tbody>




 
 



 <tbody>

  <tr>
    <th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
    <td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
    <th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">55</font></th>
    <td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">        <span class="k">struct</span> <span class="n">ast_sockaddr</span> <span class="n">stun_addr</span><span class="p">;</span></pre></td>
  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Why do we need to keep the server address in memory? (Keeping DNS resolution results in memory is an anti-pattern.)

It seems to me that we can just call connect() on the STUN socket and forget about the server&#39;s address. When we create the socket, we resolve the host name, create the socket, connect() it, and discard the server address. When a STUN request fails or times out, we close() the socket and create a new one, starting with the DNS resolution.</pre>
 </blockquote>



 <p>On November 28th, 2011, 4:43 p.m., <b>rmudgett</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1) We do not want to re-resolve the DNS address every time the external address is polled because the resolved address could change and result in a different external NAT address.
2) The call to ast_stun_request() takes socket and destination address parameters.
3) The socket cannot remain open between calls because our IP address could change.  This is the initial reason for the patch.
4) Keeping the socket open between polls needs the stun_purge_socket() hack.</pre>
 </blockquote>





 <p>On November 29th, 2011, 7:33 a.m., <b>Simon Perreault</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1) I&#39;m not suggesting we re-do the DNS lookup for every STUN query.
2) That would mean the STUN API needs to be fixed. Not fixing an API design issue when you can just causes more issues down the road.
3) Yes the socket can remain open. When the IP address changes, the next call to send() should return an error which can be handled the same way as a timeout condition.
4) stun_purge_socket() is wrong and should be fixed. The STUN code needs to use transaction IDs to associate responses with requests.

It looks like the STUN code needs to be fixed before res_stun_monitor can be implemented correctly.</pre>
 </blockquote>







</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Doing a more invasive STUN redesign is beyond the scope of this patch.  Yes, the STUN code should match transaction ID&#39;s for the associated response.
</pre>
<br />

<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On November 24th, 2011, 7:20 a.m., <b>Simon Perreault</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
 <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
    <a href="https://reviewboard.asterisk.org/r/1595/diff/3/?file=21848#file21848line326" style="color: black; font-weight: bold; text-decoration: underline;">/branches/1.8/res/res_stun_monitor.c</a>
    <span style="font-weight: normal;">

     (Diff revision 3)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
   <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static int setup_stunaddr(const char *value)</pre></td>

  </tr>
 </tbody>




 
 



 <tbody>

  <tr>
    <th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
    <td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
    <th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">255</font></th>
    <td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">                <span class="cm">/* It is an IP address and not a host name. */</span></pre></td>
  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Why do you need to determine if it&#39;s a host name or an address literal? Only netsock2 code should care about that. Why is it important for res_stun_monitor to know that?</pre>
 </blockquote>



 <p>On November 28th, 2011, 5:17 p.m., <b>rmudgett</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1) It avoids a potential memory allocation failure path if the value is an address literal.
2) Like ast_dnsmgr_lookup() it avoids the need to do repeated DNS lookups if the value is an address literal.

ast_sockaddr_parse() is a netsock2 API call.</pre>
 </blockquote>





 <p>On November 29th, 2011, 7:35 a.m., <b>Simon Perreault</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1) Isn&#39;t this premature optimization? Furthermore, one less memory allocation would not fix anything in low memory conditions: you would still run out of memory not very far down the road when other code tries to allocate memory.
2) netsock2 should not perform DNS lookups for address literals. If it does, then it&#39;s a bug. Code using netsock2 should not try to detect address literals to avoid DNS lookups since that is netsock2&#39;s job.</pre>
 </blockquote>







</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">OK, I&#39;ll not check for an address literal since my reasons are weak.
</pre>
<br />




<p>- rmudgett</p>


<br />
<p>On November 29th, 2011, 7:15 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:15 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 periodically if the new stunservermonitor option is enabled.</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>