<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/2660/">https://reviewboard.asterisk.org/r/2660/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On August 5th, 2013, 5:37 p.m. CEST, <b>Matt Jordan</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;">First, thanks for IPv6-ifying chan_iax2. It&#39;s been a long time coming, and I think *every* AstriDevCon we talk about it, try to make it a priority, and it never seems to quite get done. Or even started, really. So - thanks!

Olle mentioned on the asterisk-dev mailing list (http://lists.digium.com/pipermail/asterisk-dev/2013-July/061189.html) that this does suffer from a lack of support for the happy eyeballs RFC - see http://tools.ietf.org/html/rfc6555. I didn&#39;t see the branch he was referring to in his branch index (http://svn.asterisk.org/svn/asterisk/team/oej/00INDEX/branch-directory.txt) - but I could be missing it.

So, I&#39;m not sure how much the lack of happy eyeball support impacts this work. I would hope that the management of the dual stack would occur at a lower layer than the chan_iax driver - having each of the channel drivers attempt to manage the IPv6/IPv4 fallback would get messy very quickly. At the same time, given that chan_iax tracks a peer based on its current address, there may be some ripple effects back up into chan_iax2. I&#39;m not sure if this would have to change given Olle&#39;s patches.

Olle - what patches are you referring to? And can that work occur at a lower layer than the channel drivers?
</pre>
 </blockquote>




 <p>On August 29th, 2013, 12:42 a.m. CEST, <b>Michael Young</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;">Yes, it has been on my list of things I wanted to do (don&#39;t ask me why) when starting to help IPv6-ify parts of Asterisk.  I started it last year before or around when 11 was released.  Never could get back to debugging it and polishing it up.

I saw Olle&#39;s post and wasn&#39;t sure either which branch to look at.  I was kind of waiting for someone to respond like you did here.  My initial reaction was &quot;Oh crap.  I hope that it doesn&#39;t have to be done in the channel driver.  That should be handled elsewhere.&quot;  From a quick look, it would seem that dnsmgr.c and acl.c would need to be changed and then the channel driver would need to be updated to work with those changes.  So, I personally feel it is out of the scope of this work but it is something that needs to be fixed.  I believe this is an overall issue that affects other parts of Asterisk and not just this channel driver.</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Happy Eyeballs for UDP is something we still discuss in the IETF and the SIP Forum. There&#39;s no elegant solution in SIP. We might end up simply recommending TCP only for happy eyeballs-situations and different host names for IPv4/ipv6 servers. For media, ICE is the way to find a working flow.

The problem is finding a working flow if client and server is both dual stack. If one of the protocols doesn&#39;t have a working flow between the endpoints, there are long timeouts. In HTTP around 20 seconds, in SIP with default timers 32 seconds. This is not acceptable for a phone call. So we do need to consider this.

What I did in code was to handle the DNS SRV records properly, which is the simple part. It&#39;s in &quot;pgtips&quot;. If you have an IPv4 only client, and the first priority hostnames only resolve to IPv6, you should go to next priority. (and opposite). If you have a dual stack client, you should try all IP addresses for a host name before trying next host in your list. You can end up with multiple A and AAAA records, which all should be tried. 

With Happy Eyeballs the application sets up connections in parallell, with a small priority for one address family (by default IPv6, but policy can change that). The first one that succeeds is selected. As UDP is connectionless, the protocol needs to handle this, which has turned out very hard for SIP. We don&#39;t want to send TWO SIP messages, end up with multiple registrations and other weird stuff.</pre>
<br />










<p>- Olle E</p>


<br />
<p>On August 29th, 2013, 6:29 a.m. CEST, Michael Young wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/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 Michael Young.</div>


<p style="color: grey;"><i>Updated Aug. 29, 2013, 6:29 a.m.</i></p>







<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-22025">ASTERISK-22025</a>


</div>



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


<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;">This patch adds the ability to bind and communicate over IPv6 addresses using chan_iax2.</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;">Successfully made calls using iax2 over IPv6 between two dev machines.  SIP Softphone -&gt; dev vm (iax2 ipv6) -&gt; (iax2 ipv6) dev box -&gt; SIP ITSP -&gt; mobile phone</pre>
  </td>
 </tr>
</table>


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

 <li>/trunk/main/netsock.c <span style="color: grey">(397908)</span></li>

 <li>/trunk/main/acl.c <span style="color: grey">(397908)</span></li>

 <li>/trunk/include/asterisk/acl.h <span style="color: grey">(397908)</span></li>

 <li>/trunk/channels/iax2/parser.c <span style="color: grey">(397908)</span></li>

 <li>/trunk/channels/iax2/include/parser.h <span style="color: grey">(397908)</span></li>

 <li>/trunk/channels/iax2/include/iax2.h <span style="color: grey">(397908)</span></li>

 <li>/trunk/CHANGES <span style="color: grey">(397908)</span></li>

 <li>/trunk/channels/chan_iax2.c <span style="color: grey">(397908)</span></li>

</ul>

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







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








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