Re: [Serusers] NAT & RTPPRoxy - sr-users

5 Sep 2003

At 10:55 AM 9/3/2003, Gary Brewer wrote:
...
 Hi,

I have come across a similar problem. I want to use the A/V facilities of
Windows Messenger if one or both of my clients are behind a NAT. I realise
that it seems to be impossible to get this to work if the NAT is symmetric.
(See: RFC3489 "Applicability Statement")

If only one of my clients is behind a NAT then it would seem I would have to
communicate my NATs external address and port mapping to the non-NAT'd
client (possibly with the help of STUN) in my SIP Invite SDP message. I
would also have to setup UDP mappings for SIP, RTP/RTCP Audio Video on my
NAT. Are my A/V port mappings also included in the Invite SDP message? 
If your client is STUN-enabled, then all ports are patched with their
public equivalents. You don't need to set anything on your NAT.
One-NAT-only is not sufficient for success though -- you still may run 
into troubles with symmetric NATs.

...
 If both clients are NAT'd then what is the
approach?  
That alone can still work -- it depends on the type of NAT.

...
 I don't see how I
register with the SIP server using an external NAT address (my guess is this
is what I would have to use if I wanted anyone on the other side of the NAT
to be able to see me).  
option 1) have the phone detected the external address and registered with it; 
          that's what STUN does (e.g., granstream)
option 2) have the server used client's external transport address and ignore
          private address inside SIP messages; that's what SER nathelper module
          does

...
 MSFT have seemed to got around this problem by
recommended everyone to use uPnP enabled NATs, which will automatically bind
to an external address on the NAT and, I assume, use this when they register
with the SIP server.

RTPProxy is here https://demo.portaone.com/~sobomax/PortaSIP/ how does
RTPProxy help in the NAT situation, does it at all? 
It does. It uses brute-force: all media hit the proxy, which behaves symmetricaly,
i.e., ignores SDP and sends media to where reverse streams come from. It should
work fairly well with most use cases, the penalty is the bandwidth.

-Jiri 