Nat stun debug irc
About
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.
Click here to expand Table of Contents
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
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 1.2.3.4 and you suddenly get 10 packets in a
row from 4.3.2.1 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