Nat stun debug irc
From FreeSWITCH Wiki
The question on how to get SIP devices working behind NAT just keeps coming up... here are some informative conversations regarding debugging particular setups that might be relevant.
<brettnem> is there anyway to connect to NATed SIP clients without RTP proxying? or is the issue that it just doesn't work with symmetric NAT? <brettnem> so any thoughts on my silly nat question? I feel like I made this work before... but maybe symmetric nat is my problem <brettnem> Just trying to think if I want to do my solution with OpenSER + RTPProxy or just plain freeswitch.. any thoughts? :) <anthm> you need it to register <brettnem> yeah, they register <brettnem> that's ok <anthm> the client behind nat has to register and register a lot to keep the path open <brettnem> really? what about options pinging? <anthm> or you can set the nat-connectile-dysfunction mode <anthm> and the server will send MESSAGE to you telling you to use stun over and over <brettnem> anthm: and that would allow me to pass RTP to other servers as long as I'm not using symmetric nat, right? <anthm> rtp fixes itself on nat <anthm> its the sip you have to worry about <brettnem> anthm: That's a freeswitch core, trick, right? you don't mean that generically, right? <anthm> yah its got a sanity check <brettnem> ok, what about symmetric nat then? <anthm> if the client advertises 220.127.116.11 and you suddenly get 10 packets in a row from 18.104.22.168 then it will adjust itself <brettnem> but if you have symmetric nat, and the packets are coming from a new location where the signalling isn't coming from, will it ever make it to the client? <brettnem> Yeah, I just don't have any control over the NAT type at the client. <anthm> as long as you can get a reply based on the same route <trixter> asterisk when nat=yes in some 1.2 series do that as well with remote ip matching, but nat must be yes which breaks other stuff <anthm> it will reply the rtp back to the same ip and port it sees rtp coming from <anthm> that takes precedence over whatever it "said" to use 100% of the time within the first 20 or so packets after an invite <trixter> is it only 20 or so packets to prevent hijacking? <brettnem> so as long as some rtp leaves the client and goes to the other <brettnem> I'd just really like to not have to proxy audio if it's not necessary and I *thought* it wasn't but with freeswitch now, and a natted cisco phone, I get no audio without the connectile dysfunction param <MikeJ> yeah.. <MikeJ> brettnem, set up stun on your cisco <brettnem> hmm. didn't know the cisco supported STUN <MikeJ> hmmm <MikeJ> that sucks <brettnem> maybe it does.. I'll look <brettnem> it has a "Nat Enabled" and "Nat Address" <CtRiX> brettnem, i think it's in sip-ua <brettnem> sip-ua? <CtRiX> ah no it's not there <CtRiX> yes sip-ua but it's not there <anthm> brettnem, the connectile dysfunction param only influences the contact address <anthm> of the sip register <anthm> it has nothing to do with media <anthm> it's essentially the same trick as the rtp <anthm> only it's not used unless you enable it <brettnem> so the rtp trick is always used then? <anthm> when something registers it will rewrite the contact to be the ip and port the reg came from instead of what it says in the packet <anthm> yes the rtp trick is auto <anthm> the sip one is manual <brettnem> so why would audio not pass without that param? am I smoking crack? <anthm> because without that param <anthm> we dont know where to send the sip msgs <anthm> to answer the call <anthm> or place a call