[Freeswitch-users] STUN binding request destination

[Fabio Margarido]

Hi there.

I'm observing different behavior on two identically configured FreeSWITCH
boxes. In my tests, FreeSWITCH'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's STUN server and the other is using my own
STUN and TURN server.

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.

On the environment configured with Google'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.

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, *but then
FreeSWITCH changes the destination of its STUN packets to the source
address it receives STUN from*. In this case the STUN negotiation is
successful and the call proceeds normally.

I'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
'disable_rtp_auto_adjust', but it's false in both cases.

Help is much appreciated.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160417/b0286b9b/attachment.html