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

[Răzvan Crainea]

Hi, Daniel!

1) I think you are absolutely right - if you have issues with phones 
that misbehave when having IPv6 contact, topology_hiding is the 
solution. There are several ways to determine whether an endpoint is 
IPv6, so this should be easy to sort out.

2) Have you considered any methods to inform Asterisk that your callee 
is IPv6 or IPv4? Perhaps if you manage to figure out what the final 
destination is, you can control the IP that Asterisk adds in SDP, and 
prevent it from advertising IPv6.
Also, did you consider using a media proxy? Something like RTPProxy set 
in a bridging mode will solve your issue too.

Anyways, thanks for documenting your "adventure", I find it really 
interesting.

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 10/24/2017 10:58 PM, Daniel Lakeland wrote:
> 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.
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users