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 (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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

See

http://www.cs.cornell.edu/projects/stunt/draft-takeda-symmetric-nat-traversa...

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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

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-traversa...

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@lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >> >> >> >_______________________________________________ >Serusers mailing list >serusers@lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > > > _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

-- Jiri Kuthan http://iptel.org/~jiri/

I think the costs of additional traffic caused by an rtpproxy are lower than the costs for implementing this very intelligent clients. And I'm sure this will lead to a lot of problems which needs a lot of time(=money) to solve.

Also, there are a lot of possible failures (NATed requests from other PCs or applications) and even free VoIP services must work. If the port guess failed, it takes some time for the client to detect the failure and retry the port allocation (e.g. are there no incoming RTP packets because of wrong port guessing or because of silence suppression?).

So, I prefer rtp proxies as they are simple and you can do the NAT traversal central without configuring every UA and every NAT.

regards, klaus

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-traversa...

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@lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serusers >>> >>> >> >> _______________________________________________ >> Serusers mailing list >> serusers@lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> > > _______________________________________________ > Serusers mailing list > serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > >

-- Jiri Kuthan http://iptel.org/~jiri/

-- Jiri Kuthan http://iptel.org/~jiri/