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@netzquadrat.de wrote:
Quoting Jan Janak jan@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