On Mar 29, 2010, at 7:41 AM, Fabio Pietrosanti (naif) wrote:
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.
You shouldn't be using Aggressive-nat-detection. If your operator is really using 1.0.0.0/8 then you need to add it to the rfc1918.auto space so it knows what is or is not nat.
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.
Again see previous comment.
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.
What system do you speak of? Auto Adj rtp? Which has zip to do with a timer. It has to do with X number of packets at the start of a call.
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).
What? We already keep the media flow thru FreeSWITCH which is the exact same behavior as canreinvite=no in Asterisk.
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
You clearly do not understand what canreinvite=no does.
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).
Please read the code and fully understand it before making these wildly wrong statements.
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.
FreeSWITCH will work in 90-95% of all NAT cases but thats going to depend on you knowing exactly how nat, sip and rtp works. Without knowing these intricate details you'll fail. /b