Hello, I'm trying to fix some issues with communication on devices that are on NAT64 networks. In this case, I'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'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. 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 *can* communicate with each other, but based on the ICE candidates provided by the local device, they don't think that they can. So, my question is, is there any "safe" 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) Best, Colin