Nat stun debug irc

From FreeSWITCH Wiki
Jump to: navigation, search

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.

Conversation 1

<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
<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 and you suddenly get 10 packets in a
          row from 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
<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
<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
<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