[Serusers] NAT traversal solution by reinvite?

[Greger V. Teigre]

Are you trying to solve NATing for devices behind the same NAT or behind 
different NATs?
If it's the second, you must remember that the NAT problem includes being 
able to traverse the NAT with packets from the outside. Normally, a 
symmetric meda stream is based on incoming packets coming on the same port 
as outgoing and the outgoing must have been initiated first. Couple this 
with the fact that restricted and port-restricted NATs will stop incoming 
from other IPs than the source of the outgoing packet and that symmetric 
will not work anyway, you may be able to solve full cone NATs.  However, 
this is the type of NAT that most STUN clients discover correctly anyway.
g-)

Federico Giannici wrote:
> 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.
>
>
> Thanks.