<div dir="ltr"><p>Hello,</p>
    <p><br></p><p>Our setup is the following:<br></p>
    <p>SIP Message transfer: Freeswitch(10.240.0.130) ----INVITE(via
      UDP)----> INTERNET ----->Proxy(185.61.149.132)
      ----INVITE(via HTTP)----> Firefox</p>
    <p>ICE Message transfer: Freeswitch(10.240.0.130) <---->
      INTERNET <-----> NAT(89.246.67.250) <----> Firefox</p>
    <p><br>
    </p>
    <p><a href="http://10.240.0.130">10.240.0.130</a>: Freeswitch</p>
    <p><a href="http://185.61.149.132">185.61.149.132</a>: Proxy for SIP Message transfer to client<br>
    </p>
    <p><a href="http://89.246.67.250">89.246.67.250</a>: Firefox client behind NAT<br>
    </p>
    <p><br>
    </p>
    <p> I've attached a pcap that was recorded on Freeswitch side. If
      you filter by "(sip || stun) && (ip.addr == 89.246.67.250
      || ip.addr == 185.61.149.132)", you'll see the connection process.</p>
    <br>
    <p>The issue is, that freeswitch does not auto change the stun port
      anymore. On source 89.246.67.250 is our firefox client.
      10.240.0.130 is the IP where freeswitch resides. Though he
      receives the stun messages from <a href="http://89.246.67.250:44953">89.246.67.250:44953</a>, he still
      sends the binding requests to <a href="http://89.246.67.250:17212">89.246.67.250:17212</a>, which is the
      srvrflx candidate that he received via sdp. <a href="http://89.246.67.250:17212">89.246.67.250:17212</a>
      was determined by Firefox using Googles STUN Server
      (<a href="http://stun.l.google.com:19302">stun.l.google.com:19302</a>).<br>
    </p>
    <p>We omited the whole STUN-Process in earlier versions of our
      application, since Firefox is behind symmetric NAT and so it does
      not make sense to use a STUN server as the discovered port is not
      reachable from Freeswitch. It is blocked by our pfSense Firewall.<br>
    </p>
    <p>Earlier versions of Freeswitch (e.g. 1.6.2) did learn the
      candidate, from which he received STUN CHECK messages and used it
      to send his check messages. But since your fix, he does not do
      this anymore. It is not a problem with chrome, since chrome
      browser sends a lot more check messages than firefox. Firefox only
      sends 4 messages and then considers the STUN Candidate check as
      failed, if he does not receive a check message on this candidate
      pair. <span lang="en">Obviously, this does not seem to be enough
        for Freeswitch to change the UDP port.</span></p><p><span lang="en"><br></span></p>
    <p>Has anyone had similar 
experiences, or can anyone help us solve the problem? <br></p><p><br></p><p>Kind regards,</p>
    <p>Marko Seidenglanz</p><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Marko Seidenglanz</div><div>Softwareentwicklung</div><div><br></div><div>Telefon: +49 351-21324-261</div><div>E-Mail: <a href="mailto:marko.seidenglanz@modima.de" target="_blank">marko.seidenglanz@modima.de</a></div><div><br></div><div>modima GmbH</div><div>Sitz der Gesellschaft: Altplauen 19, 01187 Dresden</div><div>Amtsgericht Dresden HRB: 32806</div><div>Geschäftsführer: Wolfram Gürlich</div><div>USt-IdNr: DE232950743</div></div></div></div>