Subject: Re: [Sip] Simple procedure for NAT traversal for a UA

From: Diego B <[email-masked]>
Date: Thu, 01 Feb 2007 12:18:36 +0200

Hi;
What you describe is the default procedure when you are using
STUN. But as you know, you con not relay just on STUN
to solve all the NAT problems. When the client is behind a symetric NAT
the "visible RTP port" will be relevant only from packets arriving from 
the STUN server.

Regards
Diego B

Frank W. Miller wrote:
> NAT Traversal Procedure for User Agents
>
>
> I've implemented a fairly simple but general mechanism for doing NAT
> traversal with a User Agent.
>
> 1) Open a UDP port for SIP on port number 5060
> 2) Open a UDP port for RTP on port number 5004
> 3) Send a STUN binding request out the SIP port
> 4) Send a STUN binding request out the RTP port
> 5) Record the IP address and UDP port number returned in the 
> MAPPED-ADDRESS
> attribute of the binding request response received on the SIP port (call
> this the visible SIP endpoint analagous the the ICE server reflexive 
> address)
> 6) Record the IP address and UDP port number returned in the 
> MAPPED-ADDRESS
> attribute of the binding request response received on the RTP port (call
> this the visible RTP endpoint)
> 7) Use the visible SIP endpoint addresses in things like the Contact
> header address and the Via header line in outbound requests
> 8) Use the visible RTP endpoint addresses in the SDP offer for session
> establishments
>
> This procedure seems really simple to me and seems to work well with the
> limited testing I've done.  It does require the UA to multiplex STUN on
> both the SIP and RTP ports but it only requires binding requests so,
> again its pretty simple.  This procedure is certainly a lot simpler than
> ICE but does not take into account relay servers.
>
> I would be curious on anyone else's experience with a procedure similar
> to this.  It sort of seems to take bits and pieces from things in 
> various drafts.
>
> Thanks,
> FM
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 01 Feb 2007 07:50:50 -0700

Thanks for the comments.

Aymeric Moizard wrote:
>
>
> On Wed, 31 Jan 2007, Frank W. Miller wrote:
>
> The procedure you are describing does not provide a 100% reliable way to
> get media connection established.
>
> ICE is needed for many reasons:
> * your MAPPED-ADDRESS/STUN will often provide wrong "port" number.
> * it's very usefull to provide many options for direct media connection.

Yes, this procedure does not consider direct connections.  However, if 
you have a direct connection, which I am assuming is between two hosts 
that don't have a NAT between them, then this procedure is not 
relevant.  This procedure is focused on the situation where at least one 
of the UAs is behind a NAT.

> * ICE allow to exchange a media-relay address: this is helpfull when
>   no direct connection is found because you know that when direct
>   connection is not possible, 100% of calls will have media connection
>   anyway.
>

As was mentioned, the procedure does not deal with media relay servers.

> ICE is the only reliable way to build an *optimized* service: ie a 
> service which not provide media relay if not needed.
>
>

This procedure does have some of advantages over ICE.

First, its much simpler to implement.  If you have STUN client 
processing, you really just need to redirect who sends messages and 
record some response information and you're good to go (and some 
keepalives).  I know implementation complexity that is generally not a 
priority but it is an attribute of this procedure over ICE.  Second, it 
does not require the UA to implement STUN server processing.  Again, 
easier to implement but that may or may not be important.

Third, its probably quicker and lower overhead, i.e. you don't have to 
do all the STUN messaging, and all the combinations that are required 
for ICE.  It requires two STUN binding transactions and keepalives (and 
the keepalives are required in the ICE situation as well).  And the STUN 
transactions can be done at startup time so there's no overhead when a 
call setup occurs.  In my experience (which is open Internet, not direct 
connect and not Enterprise), direct connections are not relevant and 
Relay servers are often not available.  So, this procedure may not give 
you the "optimal" service in every situation, but I think it will be 
higher performance in response time and bandwidth in the case of a UA 
with a NAT in front of it getting to the Internet, a very common case.

Thanks,
FM

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Feb 2007 15:06:34 -0800

...
> This procedure seems really simple to me and seems to work 
> well with the limited testing I've done. 

In addition to the problem with Address and Port-Dependent Mapping NATs
("Symmetric NATs"), which has already been mentioned, this technique also
requires NATs to support hairpinning (see
draft-jennings-behave-test-results-03.txt).

> It does require the UA to multiplex STUN on both the SIP and RTP
> ports but it only requires binding requests so, again its pretty
> simple.  This procedure is certainly a lot simpler than ICE but does
> not take into account relay servers.

Little of ICE's complexity is due to TURN.

-d

> I would be curious on anyone else's experience with a 
> procedure similar to this. 
> It sort of seems to take bits 
> and pieces from things in various drafts.
> 
> Thanks,
> FM
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 Feb 2007 18:25:15 -0500

Frank, this has been looked at for a long time. The solution you propose 
was the original STUN mechanism in RFC 3489. It has numerous weaknesses 
that led to the development of ICE. Of course STUN alone is simpler. It 
also doesn't work well enough.

It fails in many cases:

1. if the NAT is of the symmetric variety, this doesn't work. It doesn't 
work even if the other party is on the public Internet.

2. If the caller and called parties are behind the same NAT, even if the 
NAT is not symmetric, there is a large percentage of NAT for which this 
won't work (NATs that don't hairpin)

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 01 Feb 2007 17:05:25 -0700

Perhaps my poor reading of 3489 is showing through here.  It was not 
clear to me in that draft that STUN should be multiplexed on both the 
SIP and RTP ports.  Forgive me if the use of STUN that I outlined here 
was implicit in the RFC.

Thanks,
FM

Jonathan Rosenberg wrote:
> Frank, this has been looked at for a long time. The solution you 
> propose was the original STUN mechanism in RFC 3489. It has numerous 
> weaknesses that led to the development of ICE. Of course STUN alone is 
> simpler. It also doesn't work well enough.
>
> It fails in many cases:
>
> 1. if the NAT is of the symmetric variety, this doesn't work. It 
> doesn't work even if the other party is on the public Internet.
>
> 2. If the caller and called parties are behind the same NAT, even if 
> the NAT is not symmetric, there is a large percentage of NAT for which 
> this won't work (NATs that don't hairpin)
>
> -Jonathan R.
>
> Frank W. Miller wrote:
>
>>
>> Thanks for the comments.
>>
>> Aymeric Moizard wrote:
>>
>>>
>>>
>>>> this the visible SIP endpoint analagous the the ICE server 
>>>> reflexive address)
>> Yes, this procedure does not consider direct connections.  However, 
>> if you have a direct connection, which I am assuming is between two 
>> hosts that don't have a NAT between them, then this procedure is not 
>> relevant.  This procedure is focused on the situation where at least 
>> one of the UAs is behind a NAT.
>>
>> keepalives).  I know implementation complexity that is generally not 
>> a priority but it is an attribute of this procedure over ICE.  
>> Second, it does not require the UA to implement STUN server 
>> processing.  Again, easier to implement but that may or may not be 
>> important.
>>
>> Third, its probably quicker and lower overhead, i.e. you don't have 
>> to do all the STUN messaging, and all the combinations that are 
>> required for ICE.  It requires two STUN binding transactions and 
>> keepalives (and the keepalives are required in the ICE situation as 
>> well).  And the STUN transactions can be done at startup time so 
>> there's no overhead when a call setup occurs.  In my experience 
>> (which is open Internet, not direct connect and not Enterprise), 
>> direct connections are not relevant and Relay servers are often not 
>> available.  So, this procedure may not give you the "optimal" service 
>> in every situation, but I think it will be higher performance in 
>> response time and bandwidth in the case of a UA with a NAT in front 
>> of it getting to the Internet, a very common case.
>>
>> Thanks,
>> FM
>>
>>
>>

---

From: Frank Derks <[email-masked]>
Date: Fri, 2 Feb 2007 09:20:59 +0100

John,

I might add that even if hairpinning is supported, you may still run into 
problems if the NAT translates the external address back to an internal 
one
while an endpoint expects (and only accepts) packets from the external 
address, because that happens to be address with which it is 
communicating.

Cheers,

Frank

Jonathan Rosenberg <[email-masked]> 
2007-02-02 12:25 AM

To
"Frank W. Miller" <[email-masked]>
cc
[email-masked]
Aymeric Moizard <[email-masked]>
Subject
Re: [Sip] Simple procedure for NAT traversal for a UA
Classification

It fails in many cases:

-Jonathan R.

---

From: "Kai Vehmanen" <[email-masked]>
Date: Fri, 2 Feb 2007 14:15:49 +0200

Hi,

On 02 Feb 2007,  Frank W. Miller wrote:
>Perhaps my poor reading of 3489 is showing through here.  It 
>was not clear to me in that draft that STUN should be 
>multiplexed on both the SIP and RTP ports.  Forgive me if the 
>use of STUN that I outlined here was implicit in the RFC.

this seems to be in quite wide use. Also worth noting is rport (3581), 
which can be used to achieve a similar result for signaling (learn the 
public binding via rport and then send an updated registration). Rport 
has of course similar drawbacks as STUN (i.e. you don't really know 
whether others can reach your public contact or not, which is pretty 
bad from service deployment point of view).

I'm not sure which is more common in pre-outbound/ICE clients, rport+STUN or
STUN+STUN (signaling+RTP/SDP).

-- 
[email-masked] (Kai Vehmanen)