Testing NAT types (was: Re: [Serusers] Re: RESOLVED - nathelper / calling UAs behind symmetric NATs)

[Jan Janak]

Well, if the UAs use STUN properly, that means they use STUN only when
they detect a NAT that can be traversed with STUN, then it should work.

STUN will make the messages to look like they were coming from a UA in
the public internet and thus the nathelper will not force the RTP proxy.

UAs behind symmetric NAT should not use STUN-obtained IP addresses (because 
it would be useless anyway) and send private IP addresses. In this case the
nathelper module will detect that the UA is behind a NAT and force RTP
proxy.

  Jan.

On 05-01 23:40, salmon at netzquadrat.de wrote:
> Quoting Jan Janak <jan at iptel.org>:
> > That's too complex and I couldn't see what is this good for. There is no
> > way of notifying the registrar. Registrar can only receive REGISTER
> > requests, process them and send a reply.
> > 
> > If I understand it correctly you try to mimic STUN with SIP, but that
> > will result in unwanted overhead.
> 
> That is exactly what I am trying to do and here is why: In a network with only
> STUN-enabled UACs I want to proxy rtp soley for clients behind symmetric NATs as
> all other NATs can be traversed without external help. Trouble is, the UAS has
> no way of knowing which type of NAT a STUN enabled UAC is located behind, unless
> the UAC submits this information (e.g. Grandstream UAs append a 'warning' header
> field). To the best of my knowledge there is no defined standard to transmit
> this information and Grandstream is the only UA to carry it in a header field.
> 
> Hence, the idea of setting up a STUN like mechanism to test for the type of NAT
> a UAC is behind and store it in the registrar's location database.
> 
> Thilo
> 
> 
>