[Serusers] STUN server

[Alex Mack]

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.
>>>>>>            
>>>>>>
>>>>>LA> Good point !
>>>>>
>>>>>LA> Yes, it is true. If stun can not solve the nat problem,
>>>>>media proxy
>>>>>LA> 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?
>>>>        
>>>>
>>LA> It is not a matter of priorities. It depends on how you get your 
>>LA> mediaproxy configured. You need to be aware that nated clients 
>>LA> should use the media proxy, because of the nat problem. 
>>But, if your 
>>LA> client can find ( using stun for example ) his public 
>>ip/port, then, 
>>LA> from mediaproxy point of view, this client is not nated, 
>>and so, it 
>>LA> needs not treatment ( no fixing from part of media proxy ).
>>
>>LA> You can always do this: Get every traffic proxied along 
>>mediaproxy. 
>>LA> But, if clients can talk to each other being able to bypass 
>>LA> mediaproxy, why should you proxy your communications ???
>>
>>LA> Hope to be clear
>>
>>LA> Regards,
>>
>>LA> 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