On 2014/10/24 11:00, Rod Whitworth wrote: > None of the STUN etc that have arrived, since I last looked, any good?
STUN can help with weak forms of NAT as used on some simpler routers but won't help with a symmetric NAT (i.e. one that checks both the port numbers and addresses, like PF - if you're only used to PF NAT then reading a description of full cone NAT might come as a surprise ;) For symmetric NAT, one way or another you need the call media to come from a known point that the side behind NAT communicates with. The simple way to do this is by ignoring the addresses in SIP/SDP headers, using the packet addresses instead, and always proxying call audio (media), replying to the same port that they see your media coming from. "comedia mode". This is quite commonly used in voip providers (either on their SIP registration servers, or via separate SBCs - session border controller appliances). There are other ways to do it, which can reduce (or at least spread) resource use on the provider side in situations with weak NAT / fully open SIP devices, but they mean 1) several different methods used on the provider side used in different situations (harder to debug) and 2) relying on the client to correctly implement more modern protocols. If I was a big voip provider I would likely only want to use these methods if I controlled the client side software as well as the server. In any event they only optimize decreasingly common cases. It's a different case for wholesale providers rather than the type of provider you'd use directly for phones - in that situation, it's fairly important for them to be able to split media and signalling (both for flexibility and to reduce latency) but making it easy for clients behind NAT isn't really a concern. Even in those cases you can often still work behind NAT without any special protocols (most phones/ATAs let you set your known external IP to use in headers, send frequent "keepalives", and choose a particular port range for RTP - then port forwarding takes care of the rest). Summary: try it the easy way first - ignore all this stuff, just put the phone behind NAT without anything special, and see if it works. If it doesn't then try plan B. If it still doesn't work, you can get clues by watching pflog and the SIP messages (it's a text based protocol; "tcpdump -s 1500 -A port 5060" will be readable, though "ngrep -d <iface> -W byline port 5060" is probably easier on the eye).
