<div dir="ltr">Hi there.<div><br></div><div>I&#39;m observing different behavior on two identically configured FreeSWITCH boxes. In my tests, FreeSWITCH&#39;s peer is a WebRTC web app. The only observable difference between the two environments is than one of the web apps is configured with Google&#39;s STUN server and the other is using my own STUN and TURN server.</div><div><br></div><div>In both cases, the browser runs behind a NAT which exposes different public addresses for different request, so the public address discovered with STUN and placed in the ICE candidates ends up being different than the source address of the STUN binding request that is sent to FreeSWITCH.</div><div><br></div><div>On the environment configured with Google&#39;s STUN, I see FreeSWITCH sending a STUN binding request to the address present in the ICE candidates, then receiving a STUN binding request from a source address different than the candidate, and this mismatched exchange keeps happening, STUN is never properly negotiated and the call has no audio.</div><div><br></div><div>On the env with TURN configured, I see FreeSWITCH sending a STUN binding request to the address in the candidates, then receiving a STUN binding request from a source address different than the candidate, <b>but then FreeSWITCH changes the destination of its STUN packets to the source address it receives STUN from</b>. In this case the STUN negotiation is successful and the call proceeds normally.</div><div><br></div><div>I&#39;d like to know if FreeSWITCH indeed changes the STUN destination based on the source, and if it does, why it might not be doing that on one of my envs. The only flag that struck me as possibly involved in this is &#39;disable_rtp_auto_adjust&#39;, but it&#39;s false in both cases.</div><div><br></div><div>Help is much appreciated.</div><div><br></div><div>Thanks. </div></div>