[Serusers] NAT traversal solution by reinvite?

Federico Giannici giannici at neomedia.it
Wed Aug 31 16:21:41 CEST 2005

I'd like to ask to somebody with more knowledge of me if a possible 
solution to NAT traversal is really feasible.

For various reasons, we DON'T want to use an RTP proxy.
We'd like to avoid the use of STUN because: 1) creates hairpin problems; 
2) many UAC have a bad STUN client code implementation; 3) it requires 
additional configuration by the final user.

It seems to me that with the nathelper's message rewriting functions it 
is possible to solve every problem for the SIP protocol.

Moreover, as we have the REAL IP of the UA (in the original SIP 
messages) we could also avoid haipin problems: it is sufficient to use 
the original IP/Port of the two UAs if both have the same natted IP (ie 
they are behind the same NAT). This doesn't work when the UAs are behind 
multiple NATs, but this is a relatively uncommon case.

So, the unresolved problem is with the RTP data, because we don't know 
what will be the NATted port so we cannot correctly mangle the SDP data 
in the INVITE message.

Am I correct up to this point?

Now, I'm asking myself if it is feasible to use a "MINI RTP Proxy" that 
receives the initial INVITEs, discovering the NATted RTP ports, and then 
IMMEDIATLY RE-INVITE the two UAs to connect directly each other. So only 
the first RTP packet is actually proxed, all subsequent traffic will be 
directly between the two UAs.
I think that something similar is done by Asterisk.

Is this feasible?

If it is, then we could have a good solution to NAT Traversal:
1) No Hairpin problems (for one NAT cases)
2) No problems of the normal RTP proxy (waste of bandwidth, longer 
delays, bad scalability).
3) Will work with all type of NATs except for symmetric ones (the same 
that work with STUN).
4) Simpler UAC configuraton: only username, password and sip server.


    |-                      giannici at neomedia.it
    |ederico Giannici      http://www.neomedia.it

More information about the sr-users mailing list