[Serusers] NAT & RTPPRoxy

Jiri Kuthan jiri at iptel.org
Fri Sep 5 03:46:35 CEST 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 




More information about the sr-users mailing list