Response I received:
Yes, ideally, that would be the case, but the underlying framework does not support FQDNs in candidates. I have some work at pr-rtcd-155 to address this, but then we are fighting with certain web browsers not supporting it either (e.g., Firefox).
Usually, setting the ICE host override should be enough to get connectivity from both inside (local network) and outside (public internet) since we should generate candidates with both addresses. I’d have to see some client logs to understand more.
First thing to try would be to force the listening address to be the local IP. This means setting RTC Server Address (UDP) and RTC Server Address (TCP) to 172.16.0.10, in this example.
Another potential workaround could be to have two local IPs pointing at the MM instance (e.g. 172.16.0.10 and 172.16.0.11) and then provide a mapping like this: 200.210.220.230/172.16.0.10,172.16.0.11/172.16.0.11