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(a)netzquadrat.de wrote:
Quoting Jan Janak <jan(a)iptel.org>rg>:
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