[Serusers] NAT traversal solution by reinvite?

[Federico Giannici]

Greger V. Teigre wrote:
> 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.

I agree with you for the case of symmetric NATs, but they wouldn't work 
with STUN neither...

For port-restricted NATs I don't understand the problem. If a re-invite 
is sent to a different IP, then the NAT will be opened for that IP when 
the UA will start the stream. Don't he?

A problem could be if, for the re-invite, the UA use a different port 
for RTP then the one used in the previous invite!
Is this permitted in the RFC?
Is this common in UAs implementation?


Thanks.



> 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. 
> 
> 
> 


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