[OpenSIPS-Users] Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

[Daniel Lakeland]

On 10/24/2017 01:41 AM, Răzvan Crainea wrote:
> Hi, Daniel!
>
> Sure, if you want to make a dual-stack tutorial for OpenSIPS, I'd be 
> more than welcome to review it.
> In the meantime, let us know if we can help you making it more robust.

Here are the current issues I'm considering:

1) How to deal with ipv4 only endpoints, ones that think that a 
destination uri like sip:foo@[2001:1a36:2021:...]:5060 means that the 
destination refers to user foo at host "[2001" on port 1 and yes this 
seems to happen.

The current strategy I have because my total endpoint count is small, is 
to list those endpoints by username in the script and detect when $ru 
has that username, and do topology hiding... this works pretty well I 
think, but it also requires SDP rewriting in case of IP type mismatch 
(fortunately, Asterisk seems to listen on ipv4 and ipv6 udp sockets). 
The general solution might be to first do a lookup, and then based on 
whether $ru is now an IPv4 address or not, decide whether to topology 
hide. My assumption is that ipv6 registered endpoints can handle both.

The issue is that when ipv6 is available, systems prefer it, and this 
makes sense. So, when Asterisk has to originate a call, it calls the 
proxy and the proxy is dual-stacked, so it calls via ipv6 and offers its 
own ipv6 as contact and SDP contents. Without topology hiding, the proxy 
passes this contact along to the ipv4 only ATA and the whole thing goes 
kablooie when the ATA can't figure out what Asterisk is talking about.

Also, these are ipv4 endpoints, and so they need some NAT help. The 
combination of topo hiding and NAT help can be an issue. But I think at 
the moment it's working, nevertheless, it's something I need to sit down 
with and read through the script and see what the right way to do it is, 
rather than the hackery I have in place.

When the call originates at one of these ipv4 only endpoints, it seems 
that Asterisk then creates replies that are ipv4 and so the problem 
doesn't occur.

2) Getting audio across ipv4/ipv6 transitions is tricky. I'm using 
Asterisk, though my ultimate goal is to switch to FreeSwitch as my 
impression is it might work better for me. At the moment, Asterisk works 
because I enable icesupport, and so it listens on ipv4 and ipv6. I don't 
enable ICE negotiation on my endpoints, I just have OpenSips rewrite the 
SDP to the appropriate one based on whether they're ipv4 or not. I do 
this because ICE support is spotty and the ATAs can't do it, and the 
softphones don't need it. But it's possible that ICE offerings are not 
working with my outbound trunks.... sporadically (based on which carrier 
my outbound trunk chooses in their least cost routing). So, for outbound 
calls on the trunk, it's possible I need to remove ICE support... since 
it's not needed there as their endpoints are IPv4 only, this may be 
fine, but still it's a gotcha people should know about. It's not clear 
to me whether Asterisk is being nice and other media servers might 
refuse to simply accept input on any socket without a proper ICE 
negotiation. In my opinion, ICE is dead in the water as first off it's 
only needed in ipv4, but second there are too many ipv4 ATAs and things 
that don't support it, and finally it's a temporary hack that will go 
away some time late in 2019 when google's ipv6 adoption curve hits more 
than 50% https://www.google.com/intl/en/ipv6/statistics.html that's 
doubling every 15 months or something like that, so we'll probably see 
40% ipv6 hits by some time early 2019 and the majority of everything 
google does will be ipv6 sometime mid 2019 (note in the US we're already 
at about 33% ipv6 to google). At that point ipv4 will be a minority 
issue for consumers, and incentives to make major changes will switch sides.