FS auto nat detection systems: are an attempt to provide alternative to STUN/ICE/TURN ?
Hi all, i would like to ask one question to all FS folks. 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. 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) . 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? Fabio
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
Michael Jerris <mike@jerris.com> 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.
Also, there are helpful pages about NAT on the FreeSWITCh wiki.
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
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
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
This is because your endpoint is an idiot and puts the wrong IP in the SDP... its going to cause us to send media to the wrong place until they send us a packet to auto adj. It is a hard situation to solve and if your endpoint can't traverse nat on its own or figure out its info then you're out of luck. Its not the registrars job or place to try to figure out your endpoints nat deficiency. Your situation is a little out of the usual so I totally expect you to find all kinds of edge cases that aren't solved by default. You do remember its SIP right? The most retarded protocol on the planet. :P /b On Mar 29, 2010, at 9:01 AM, Fabio Pietrosanti (naif) wrote:
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.
Fabio Pietrosanti (naif) <lists@infosecurity.ch> wrote:
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?
I don't understand the question but you can choose in writing your configuration how to handle NAT, including whether or not to use a STUN server.
participants (4)
-
Brian West
-
Fabio Pietrosanti (naif)
-
Jason White
-
Michael Jerris