[asterisk-dev] IPv4 and IPv6 preference

[Olle E. Johansson]

28 jul 2010 kl. 16.14 skrev Simon Perreault:

> Olle E. Johansson wrote, on 07/28/2010 03:38 PM:
>> This is really ugly, since it is based on the family of bindaddr, which is for UDP only. I see a lot of code using this as a preference, which is propably a poor solution. This limits the use and doesn't really follow the architecture we're trying to complete in asterisk with udp, tcp, tls and udptl support.
>> 
>> At least, we need some documentation on this. sip.conf.sample only has IPv6 in the ACL part. That's a BUG.
> 
> I agree it is a bug, but it's the best situation we could reach without
> completely rearchitecturing chan_sip. In my opinion, I estimate that the effort
> required to do this would exceed the total effort we spent doing the IPv6
> conversion in the first place. And we spent *a lot* of effort.
:-) I know.
But not writing documentation is not saving that much time. Write docs!

> 
>> I do want people to use IPv6, and to get there we need a working implementation and not just something that fits the "ipv6 required" checkbox... We can do better in the Asterisk community.
>> 
>> Now the question is why we only have ONE bindaddr structure. We should have at least one per family if we assume that the default setup is dual stack. Otherwise, I will have to run TWO asterisk servers - one for IPv4 and one for IPv6, which doesn't seem to be a solution.
> 
> No. Two would not be much better. We need N.
> 
> With the current situation, you can do one of four things:
> a) Listen on a specific IPv4 address.
> b) Listen on a specific IPv6 address.
> c) Listen on the IPv4 wildcard.
> d) Listen on the IPv4 and IPv6 wildcards.
> (You can choose independently for UDP, TCP, and TLS.)
Ok, add this to sip.conf.sample to explain our support. This is really IMPORTANT!

> 
> With two sockets for each transport protocol, you could pick two out of the four
> above for each transport protocol. But you could still be limited. Suppose for
> example that you want to listen on one specific IPv4 address and two specific
> IPv6 addresses.
Right. But we should at least support the dual-stack scenario with specific addresses. We have had a limitation on number of addresses for a long time and can stick with those until we resolve it all. 

I thought that by converting chan_sip to netsock2, we have released ourself of some limitations in this area, but I might be wrong.

> 
> We need N sockets of any address family and transport protocol.
> 
> And that's a big change, but is completely unrelated to IPv6. With the IPv6
> conversion we added cases b) and d) above. Before, only a) and c) were possible.
> So I certainly don't see this as a step back.
No, definitely not, but I feel it's not enough of forward motion. There is a difference between working code and a product we can release. A product need to be documented, support recommended scenarios and be useful in the situations our users have out there. With IPv6 adding multiple addresses to all my interfaces, I certainly not want it to bind to an IPv6 wildcard. And then I'm stuck to one Asterisk per address family, which is NOT a solution I want to promote. Remember that 1.8 is a long term release. We need to set the bar very high before we release a new LTS. 

> 
> What's stopping anyone from putting the diff on the review board?
Nothing, propably resource allocation. But we need to agree on what needs to be done, which of this stuff that can be in the BUG category and needs to be fixed before we release anything claiming at least a basic level of IPv6 support in chan_sip and rtp.

You've done great job with the code. Now we need to create a great product based on that code. 


/O