On 29/03/10 15.37, Brian West wrote:
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.
I need a system that is able to handle automatically that situation, i cannot continuously find out new fancy netblocks used by operator for nat. So the apply-nat-acl=rfc1918 without aggressive-nat-detection became not useful in detecting 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.
Sure, but that's clearly an incompatibility of a client feature (that detect address change and re-register with proper contact header with the public ip address) with a server feature that make nat detection with apply-nat-acl and aggressive-nat-detection fail.
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.
That's the part i don't know precisely. It's quite difficult to do RTP debugging on FS, i use tcpdump and the maximum debug level. Auto adjust RTP i think it's the feature we are speaking about that require X packets within X time to start and need the SIP UA to start RTP as earlier as possible. In a bandwidth saving environment like mobile you have to consume less bandwidth as possible starting the RTP flow only when SIP handshake has been completed, enable VAD, enable CNG and all sort of bandwidth optimization techniques. It's possible to know precisely auto adjust rtp how it works precisely? I have seen *really* strange scenarios with FS relaying RTP packets to provide IP addresses in situation when there was a very high packet loss and dropping of packets from the SIP UA with the private ip address.
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.
I tell you that's not true, are different software and it's reasonable that works differently. Asterisk with canreinvite=no can handle certain mobile to mobile communication that FS with the minor modification i have done (also with the factory settings) does not handle. Now i need carry on precise and structured testing to show off the different kind of servers how react to the different conditions and then analyze deeply how they are different. I personally strongly prefer FS to Asterisk but have to say that Asterisk with static settings canreinvite=no is more reliable than FS with the dynamic detection system (NAT detection, RTP adjusting, etc) that are prone to fail in some extreme/particular condition.
Please read the code and fully understand it before making these wildly wrong statements.
Unfortunately i am a good tlc, security and it guys but at programming i read piece of code just to isolate issues. For sure the NAT handling have situation that does not precisely identify NATted host. Then maybe the auto Rtp adjust may require some improvement. I've seen FS sending packets to 10.0.0.0 network even with an host that had AUTO-NAT in the "sofia status profile internal", so the RTP packetizer was sending data to the SIP UA internal address that was correctly identified as NATted looking at the Sofia information.
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.
I understand, it's an intricate situation, i think now i know quite well, SIP, RTP and network related issues. For that reason i am trying to explain the particular context i encountered and i would like to arrange structured testing also to report to you guys the condition and details where it does not work properly and when on other server works. It's all our common interests to make it working also in extreme condition :) Fabio