[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