[asterisk-dev] [Code Review] 2660: Add IPv6 Support To chan_iax2

Matt Jordan reviewboard at asterisk.org
Fri Aug 30 11:41:08 CDT 2013



> On Aug. 5, 2013, 3:37 p.m., Matt Jordan wrote:
> > First, thanks for IPv6-ifying chan_iax2. It'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'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'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'm not sure if this would have to change given Olle's patches.
> > 
> > Olle - what patches are you referring to? And can that work occur at a lower layer than the channel drivers?
> >
> 
> Michael Young wrote:
>     Yes, it has been on my list of things I wanted to do (don'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's post and wasn'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 "Oh crap.  I hope that it doesn't have to be done in the channel driver.  That should be handled elsewhere."  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.
> 
> Olle E Johansson wrote:
>     Happy Eyeballs for UDP is something we still discuss in the IETF and the SIP Forum. There'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'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's in "pgtips". 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't want to send TWO SIP messages, end up with multiple registrations and other weird stuff.

I think we can extend your "there's no elegant solution in SIP" to "there's no elegant solution in IAX". Both are using a similar approach to their handling of the transports.

It sounds like to handle this properly in chan_iax2, it'd need your pgtips work completed and merged. chan_iax2 would have to be updated to use that. I think I agree with Michael here - it definitely is something we should look at doing, and ideally the various channel drivers would all behave properly. On the other hand, Michael's work in this patch is still necessary and a good first step at getting IPv6 support in chan_iax2, and I'd hate to not get it in 12 - which is a standard release - while we work on something that affects chan_sip as well.

I think at this point it's worth getting this into Asterisk 12, barring any other technical problems a review finds.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2660/#review9326
-----------------------------------------------------------


On Aug. 29, 2013, 4:29 a.m., Michael Young wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2660/
> -----------------------------------------------------------
> 
> (Updated Aug. 29, 2013, 4:29 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22025
>     https://issues.asterisk.org/jira/browse/ASTERISK-22025
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch adds the ability to bind and communicate over IPv6 addresses using chan_iax2.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/netsock.c 397908 
>   /trunk/main/acl.c 397908 
>   /trunk/include/asterisk/acl.h 397908 
>   /trunk/channels/iax2/parser.c 397908 
>   /trunk/channels/iax2/include/parser.h 397908 
>   /trunk/channels/iax2/include/iax2.h 397908 
>   /trunk/CHANGES 397908 
>   /trunk/channels/chan_iax2.c 397908 
> 
> Diff: https://reviewboard.asterisk.org/r/2660/diff/
> 
> 
> Testing
> -------
> 
> Successfully made calls using iax2 over IPv6 between two dev machines.  SIP Softphone -> dev vm (iax2 ipv6) -> (iax2 ipv6) dev box -> SIP ITSP -> mobile phone
> 
> 
> Thanks,
> 
> Michael Young
> 
>

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


More information about the asterisk-dev mailing list