<div dir="ltr">Hello,<div><br></div><div>I&#39;m trying to fix some issues with communication on devices that are on NAT64 networks. In this case, I&#39;m using ICE to generate candidates for the local device before sending an INVITE to FS; however, because the device is on (what it perceives to be) an IPv6-only network, and FS is on an IPv4-only network, the device simply can&#39;t generate create a candidate that would be accepted by FS. FS essentially rejects all IPv6 candidates and then rejects the call with a 488.</div><div><br></div><div>However, if I add a random IPv4 address in the INVITE that is accepted by the apply-candidate-acl in FS, then once the device starts sending RTP data to Freeswitch, auto-adjust kicks in and everything is fine. In other words, the two devices <i>can</i> communicate with each other, but based on the ICE candidates provided by the local device, they don&#39;t think that they can.</div><div><br></div><div>So, my question is, is there any &quot;safe&quot; bogus IP I can provide to FS that will essentially allow the call to start, knowing it will just blackhole any RTP data for that client until auto-adjust has found the proper destination? Any other suggestions to solve this? (Besides using STUN, which - even if used - is still only going to generate an IP address with almost certainly an invalid port)</div><div><br></div><div>Best,</div><div>Colin</div></div>