The situation you describe should not require anything not in the default configs of FreeSWITCH. If its not working, please try reverting the configuration COMPLETELY back to the original configuration and it should work fine, then figure out what you changed to break it. On Mar 28, 2010, at 5:44 AM, Fabio Pietrosanti (naif) wrote:
I am really struggling against the automatic nat system of FS, where the full logic is still not really really clear and causing a lot of headheache.
No need to struggle, it works without changing anything.
Where on asterisk with a simple canreinvite=no everything works fine (even between dirty nat) on FS it does not work and FS start sending RTP to provide ip address on 10.0.0.0/8 (even if there is apply-nat-acl=rfc1918.auto) .
What configuration have you changed?
However, independently from the bugs of the automatic nat handling systems that have with the time to be noticed, discovered, fixed, etc, etc, my question is:
All this method for dynamic nat detection and handling of FS, want to be an alternative to the STUN/ICE/TURN approach of VoIP standard protocol?
sometimes you simply can not avoid this approach, we have augmented it by throwing a little bit of upnp, natpmp, stun, and simple logic to get it right as much as it can. Mike