[Serusers] NAT traversal solution by reinvite?

Greger V. Teigre greger at teigre.com
Thu Sep 1 15:29:00 CEST 2005


>> Exactly, but this is not the UA, it's the NAT allocating the port (you 
>> didn't answer whether you are solving the problem of two UAs behind same 
>> NAT or behind different NATs).
>
> I don't understand your question.
<
> I'm tring to solve the more general case as possible.
> Moreover, I'm tring to solve hairpin problems for UAs behind the same NAT 
> (and only one).

The general case is where you don't make any assumptions about where the UAs 
are. If you are only talking about UAs you definitely know are behind the 
same NAT, the scenario is different than what I assumed you were talking 
about. If you know the UAs are behind the same NAt, why not put SER behind 
the same NAT?

Or you can just use fix_nated_register and not do any mangling with SDP at 
all (if the UAs don't use STUN and assuming the NAT does not have a SIP 
ALG). As long as the private addresses are internally routable, you should 
be fine.

> All of this without proxing the RTP streams (just a couple of packets).

?? A couple of packets?

>
>> The UA will probably use the same port, but a reINVITE may even change 
>> IP... The problem is the NAT allocating another port on the public 
>> interface.
>
> But the various kinds of "cone NATs" should allocate always the same port 
> (for the same internal IP/Port). This is the assumption on which STUN is 
> based!

Yes, and also the reason for why many STUN implementations fail. Many people 
don't know that there are more variants of NATs than those specified in the 
STUN RFC...
g-)


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




More information about the sr-users mailing list