Well, i noticed that several way for FS to detect NAT does not detect NAT. For example i have several operators that assign NATted ip address in network 1.0.0.0.0/8 that are not matched by apply-nat-acl=rfc1918.auto . The only way to match it is to use aggressive-nat-detection. But if you enable aggressive-nat-detection with PJSIP that have an auto-nat feature that detect an IP address change and re-register with adjusted Contact header, FS will not detected the host as NATted. Other than this, i understood that FS have several dynamic methods to adjust the RTP relaying system. While using VoIP under mobile environment, where latency could be very high, maybe some of this system just does not work because of some timer expires. Now i am entering into deep analyzing of all those issues, however just now i can confirm that Asterisk with canreinvite=no handle several situation that FS with default-factory settings does not handle (when using mobile voip). So for all the dynamic system of FS it would be really nice to be able to have some "static" method that just behave like the Asterisk canreinvite=no statically, without dynamic discovery methods where the heuristic could be easily tweaked/mismatch when running in particular environment such as mobile characterized by: - High packet loss - High Delay (especially in SIP signaling over TCP) - NAT with translated address also in non-rfc1918 addresses Just consider that to make working properly SIP over GPRS the T1 has to be setup to at least 3s instead of 500ms, that a full INVITE to be closed could take even 15-20s, so all the timing and timers that could exists around the FS dynamic system could break in such conditions (still not analyzed into the code). Now i am going to arrange a test bed with Asterisk, FreeSWITCH and OpenSER+RTPProxy to see how different servers behave differently in various NAT situation with their stock factory default configuraiton and/or little changes. Ciao, Fabio Pietrosanti On 28/03/10 12.03, Michael Jerris wrote:
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?
Had to change NDLB-tls-connectile-dysfunction mandatory because other SIP/TLS does not work. Without NDLB-tls-connectile-dysfunction FS try to open a socket to the NATted hosts that obviously cannot receive inbound TCP connections. inbound-proxy-media=true In order to simplify the handling of NAT i just enable this to force media relay and does not let bypass_media to be activated. <param name="aggressive-nat-detection" value="true"/> This is to detect conditions where the apply-nat-acl does not work because the Contact header reports private ip address in NAT where the IPs are not rfc1918 (2 mobile operator of 4 have this network setup).
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.
Probably will go also in that direction later but i think mainly to goes with RTP over TCP when UDP is blocked. I think that, if we force the media relay, when outgoing UDP connection from the SIP UA are allowed everything should work right? Fabio