[asterisk-dev] IPv4 and IPv6 preference

[Olle E. Johansson]

28 jul 2010 kl. 16.48 skrev Simon Perreault:

> Trying to keep the discussion on the technical side...
:-) I was jus trying to explain why I don't think "listening to IPv6" is enough. We need functionality as well...

> 
> Olle E. Johansson wrote, on 07/28/2010 04:26 PM:
>>> 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 agree that two sockets would be a step better. But I fail to see how it would
> be any easier to go from 1 to 2 than it would be to go from 1 to N. If we're to
> do this, let's go directly to N. We wouldn't be gaining anything by doing an
> intermediate step.
I was trying to reduce the requirements, but if it's the same, let's go. We need it for TLS connections too. One socket per domain we support and one cert per socket.

> 
>> I thought that by converting chan_sip to netsock2, we have released ourself of some limitations in this area, but I might be wrong.
> 
> No, the situation is exactly the same, and netsock2 is not concerned with this.
> This is a chan_sip-specific issue. I don't expect that fixing this would imply
> touching netsock2 at all.
Ok.
> 
>>> 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. 
> 
> I don't agree on the use of the "product" term, but I definitely agree that this
> is an important feature that needs to get implemented.
Ok. THanks.
> 
> That's all the non-technical opinion I will be allowing myself to send to
> asterisk-dev@ for now.


:-)

/O