[Serusers] STUN server

[Greger V. Teigre]

> There's another problem with STUN:
> If you have two UAs behind the *same* (not symmetric) NAT and the NAT
> doesn't support hairpinning (i.e. sending data back in the direction
> of the source in order to reach the target) RTP traffic won't work.
> Each client tries to send its RTP stream to the external port of the
> firewall which in this case wouldn't send the packets back into the
> net. So those 2 UAs wouldn't be able to communicate when traffic
> isn't handled by an external RTP Relay (e.g. MediaProxy, RTPProxy,
> etc.)

Well, that's true, but you can test to see if the public IP of caller and 
callee is the same. Of course, you cannot be completely sure whether there 
are a couple of other NATs behind the public one, but just in case, you 
should proxy the call to avoid the hairpinning problem.

> The WinStun-Client from Vovida can detect if your NAT supports
> hairpinning.

Which of course doesn't help much, because you need to rely on the user 
client's STUN implementation.
g-)

> Talking about priorities: STUN beats Mediaproxy, because SER can't
> distinguish between a NAT'ed STUN client and a client with a real
> public IP. That's no problem as long as you don't have two UAs behind
> the same hairpinning-disabled NAT.

Alex Mack wrote:
> Lucas Aimaretto schrieb:
>
>>>>>>>>>> Make sure you are not behind a Symmetric NAT. If
>>>>>>>>>>
>>>>>>>>>>
>>> so, you're
>>>
>>>
>>>>>>>>>> dead. STUN does not work with Symmetric NAT.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> If a UA is behind Symmetric NAT, and
>>>>>>>>> UA use STUN, and
>>>>>>>>> SER have [RTP/Media]Proxy to handle Symmetric NAT, this UA
>>>>>>>>> should be fine, right?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Yes, but, if UA is behind symmetric NAT, I would not
>>>>>>>>
>>>>>>>>
>>> configure
>>>
>>>
>>>>>>>> STUN to it. I'd just led mediaproxy solve the problem.
>>>>>>>>
>>>>>>>>
>>>>>>> But if you have 100 clients,
>>>>>>> it would be hard to put all clients in one group.
>>>>>>>
>>>>>>>
>>>>>>> Good point !
>>>>>>
>>>>>>> Yes, it is true. If stun can not solve the nat problem,
>>>>>> media proxy
>>>>>>> should fix it with no trouble at all.
>>>>>>
>>>>>>
>>>>>>
>>>>> If there is no symmetric NAT and I have installed STUN and
>>>>> Mediaproxy on my server. Which one will have higher priority
>>>>> to handle this call session? Is it always STUN? Of course if
>>>>> I don't need to pass the call to PSTN gateway. Just IP-phone
>>>>> to IP-phone. Can you set the priority in ser.cfg? and how?
>>>>>
>>>>>
>>>> It is not a matter of priorities. It depends on how you get your
>>>> mediaproxy configured. You need to be aware that nated clients
>>>> should use the media proxy, because of the nat problem.
>>> But, if your
>>>> client can find ( using stun for example ) his public
>>> ip/port, then,
>>>> from mediaproxy point of view, this client is not nated,
>>> and so, it
>>>> needs not treatment ( no fixing from part of media proxy ).
>>>
>>>> You can always do this: Get every traffic proxied along
>>> mediaproxy.
>>>> But, if clients can talk to each other being able to bypass
>>>> mediaproxy, why should you proxy your communications ???
>>>
>>>> Hope to be clear
>>>
>>>> Regards,
>>>
>>>> Lucas
>>>
>>>
>>>
>>> Thank you, it makes sence.
>>> It would be the best solution I'd say, but it reminds me
>>> JavaRocks statement that STUN makes problems in some
>>> circumstances.. Just wondering what problems? Maybe some UA's
>>> not supporting STUN?
>>>
>>>
>>
>> The only circumstances that I know where STUN does not help is when
>> the UA is located behind a symmetric nat. In the othre 3 cases of
>> nat, it should help you just fine. Or if the clients do not
>> implement a good stun-client or the stun server does not implement
>> the protocol correctly. But, let say that every body follows the
>> standars ( JA!, ask cisco ) ... you should not have problems at all.
>>
>> Regards,
>>
>> Lucas
>>
>>
>>
>
> Hi everyone!
>
> There's another problem with STUN:
> If you have two UAs behind the *same* (not symmetric) NAT and the NAT
> doesn't support hairpinning (i.e. sending data back in the direction
> of the source in order to reach the target) RTP traffic won't work.
> Each client tries to send its RTP stream to the external port of the
> firewall which in this case wouldn't send the packets back into the
> net. So those 2 UAs wouldn't be able to communicate when traffic
> isn't handled by an external RTP Relay (e.g. MediaProxy, RTPProxy,
> etc.)
> The WinStun-Client from Vovida can detect if your NAT supports
> hairpinning.
> Talking about priorities: STUN beats Mediaproxy, because SER can't
> distinguish between a NAT'ed STUN client and a client with a real
> public IP. That's no problem as long as you don't have two UAs behind
> the same hairpinning-disabled NAT.
>
> Alex Mack
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers