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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
