[Serusers] STUN and Symmetric NAT

Simon Barber simon at superduper.net
Tue Mar 16 17:05:07 CET 2004


Takeda points out in his draft that you will need port prediction (or 
TURN / permanent rtp proxy) to communicate between port restricted cone 
NAT and symmetric NAT - not just symmetric -> symmetric.

Simon


Simon Barber wrote:

> I would certainly agree that for commercial VoIP service between 
> enterprises - this is too brittle. For free or cheap VoIP service 
> between home users, who often have very few devices behind the NAT and 
> little traffic - this solution might give enough reliability.
>
> Simon
>
>
> Jiri Kuthan wrote:
>
>> To me, this sounds too brittle. -jiri
>>
>> At 03:43 PM 3/16/2004, Simon Barber wrote:
>>  
>>
>>> See
>>>
>>> http://www.cs.cornell.edu/projects/stunt/draft-takeda-symmetric-nat-traversal-00.txt 
>>>
>>>
>>> for a description of how to traverse many dual symmetric NAT 
>>> situations - by port prediction. It's only not possible to traverse 
>>> dual symmetric NAT if both symmetric NATs cannot have their ports 
>>> predicted.
>>>
>>> Simon
>>>
>>>
>>> Klaus Darilion wrote:
>>>
>>>   
>>>
>>>> Switching is not possible with symmetric NAT. But if only one of 
>>>> the clients is behind symmetric NAT, you don't need an rtpproxy, if 
>>>> the other client can act as "passive" client.
>>>>
>>>> see 
>>>> http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-nat-scenarios-00.txt 
>>>> section 2.2.1.6 Receiving an Invitation to a Session
>>>> a=active, a=passive
>>>>
>>>> Klaus
>>>>
>>>>
>>>> Simon Barber wrote:
>>>>
>>>>     
>>>>
>>>>> My confusion over symmetric / cone NAT. But does look possible to 
>>>>> communicate between symmetric NATs in many cases - but first 
>>>>> starting with RTP proxy or TURN. Using the RTP proxy to learn 
>>>>> which class of symmetric NAT you have, and predicting the port 
>>>>> allocation - then switching to direct communication if the port 
>>>>> prediction test gives good results.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>> Jiri Kuthan wrote:
>>>>>
>>>>>       
>>>>>
>>>>>> At 07:16 PM 3/15/2004, Simon Barber wrote:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> possible way to get through symmetric NAT without permanent 
>>>>>>> rtpproxy.
>>>>>>>
>>>>>>> Initiate the connection using rtpproxy, as normal. Now, learn 
>>>>>>> the udp port the NAT is sending RTP from. Now send a re-invite 
>>>>>>> to both parties, and switch the stream to the udp port the NAT 
>>>>>>> is using, instead of the rtpproxy. This will only work if the 
>>>>>>> NAT uses the same external ip/port pair when the same internal 
>>>>>>> ip/port pair is used
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>>
>>>>>> Which is non-symmetric NAT. Symmetric NATs are only traversable 
>>>>>> the way
>>>>>> Klaus described.
>>>>>> -jiri
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> (and I'm expecting that most sip phone will reuse the same 
>>>>>>> internal ip/port pair when you re-invite). Apparently some NATs 
>>>>>>> do this. (although I'm not a NAT expert - I have only read a few 
>>>>>>> papers on the subject).
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>> Klaus Darilion wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>> You can't overcome symmetric NAT with STUN. To traverse a 
>>>>>>>> symmetric NAT you need:
>>>>>>>> - A SIP proxy with NAT traversal (nathelper module)
>>>>>>>> - An RTP proxy (or an generic TURN server and a SIP UA which 
>>>>>>>> supports TURN)
>>>>>>>> - A symmetric SIP UA (symmetric SIP & symmetric RTP)
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Klaus
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>             
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> Can someone please help me if my dialer does not support 
>>>>>>>>> symmetric
>>>>>>>>> signalling,  is there anyway to go through symmetric nat 
>>>>>>>>> through the server
>>>>>>>>> or configure from the server that asking the dialer to point 
>>>>>>>>> to a STUN
>>>>>>>>> server before reaching the UA. Please help........
>>>>>>>>> regards, shirley
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Serusers mailing list
>>>>>>>>> serusers at lists.iptel.org
>>>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Serusers mailing list
>>>>>>>> serusers at lists.iptel.org
>>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>>               
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Serusers mailing list
>>>>>>> serusers at lists.iptel.org
>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Jiri Kuthan            http://iptel.org/~jiri/
>>>>>>
>>>>>>         
>>>>>
>>
>> -- 
>> Jiri Kuthan            http://iptel.org/~jiri/
>>  
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list