Hello,

Our setup is the following:

SIP Message transfer: Freeswitch(10.240.0.130) ----INVITE(via UDP)----> INTERNET ----->Proxy(185.61.149.132) ----INVITE(via HTTP)----> Firefox

ICE Message transfer: Freeswitch(10.240.0.130) <----> INTERNET <-----> NAT(89.246.67.250) <----> Firefox

10.240.0.130: Freeswitch

185.61.149.132: Proxy for SIP Message transfer to client

89.246.67.250: Firefox client behind NAT

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.

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 89.246.67.250:44953, he still sends the binding requests to 89.246.67.250:17212, which is the srvrflx candidate that he received via sdp. 89.246.67.250:17212 was determined by Firefox using Googles STUN Server (stun.l.google.com:19302).

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.

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. Obviously, this does not seem to be enough for Freeswitch to change the UDP port.

Has anyone had similar experiences, or can anyone help us solve the problem? 

Kind regards,

Marko Seidenglanz

--