[Serusers] NAT traversal solution by reinvite?

[Federico Giannici]

Richard Z wrote:
> I think that the natted rtp port might be changed after the reinvite 
> because the traffic is not going to the original ip:port of the 
> rtpproxy. So it is probably not going to work.


The port will change only with symmetric NATs, but in my experience they 
are relatively rare, and anyway they wouldn't work with STUN too...

Bye.



> On 8/31/05, *Federico Giannici* <giannici at neomedia.it 
> <mailto:giannici at neomedia.it>> 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
>     <mailto:giannici at neomedia.it>
>         |ederico Giannici       http://www.neomedia.it
>     ___________________________________________________
> 
>     _______________________________________________
>     Serusers mailing list
>     serusers at lists.iptel.org <mailto:serusers at lists.iptel.org>
>     http://lists.iptel.org/mailman/listinfo/serusers
> 
> 


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