Richard Z wrote:

I think that the natted rtp port might be changed after the reinvite because the traffic is not going to the original ip:port of the rtpproxy. So it is probably not going to work.

The port will change only with symmetric NATs, but in my experience they are relatively rare, and anyway they wouldn't work with STUN too...

Bye.

On 8/31/05, *Federico Giannici* <giannici@neomedia.it mailto:giannici@neomedia.it> wrote:

I'd like to ask to somebody with more knowledge of me if a possible
solution to NAT traversal is really feasible.

For various reasons, we DON'T want to use an RTP proxy.
We'd like to avoid the use of STUN because: 1) creates hairpin problems;
2) many UAC have a bad STUN client code implementation; 3) it requires
additional configuration by the final user.

It seems to me that with the nathelper's message rewriting functions it
is possible to solve every problem for the SIP protocol.

Moreover, as we have the REAL IP of the UA (in the original SIP
messages) we could also avoid haipin problems: it is sufficient to use
the original IP/Port of the two UAs if both have the same natted IP (ie
they are behind the same NAT). This doesn't work when the UAs are behind
multiple NATs, but this is a relatively uncommon case.

So, the unresolved problem is with the RTP data, because we don't know
what will be the NATted port so we cannot correctly mangle the SDP data
in the INVITE message.

Am I correct up to this point?

Now, I'm asking myself if it is feasible to use a "MINI RTP Proxy" that
receives the initial INVITEs, discovering the NATted RTP ports, and then
IMMEDIATLY RE-INVITE the two UAs to connect directly each other. So only
the first RTP packet is actually proxed, all subsequent traffic will be
directly between the two UAs.
I think that something similar is done by Asterisk.

Is this feasible?

If it is, then we could have a good solution to NAT Traversal:
1) No Hairpin problems (for one NAT cases)
2) No problems of the normal RTP proxy (waste of bandwidth, longer
delays, bad scalability).
3) Will work with all type of NATs except for symmetric ones (the same
that work with STUN).
4) Simpler UAC configuraton: only username, password and sip server.


Thanks.

--
___________________________________________________
     __
    |-                      giannici@neomedia.it
<mailto:giannici@neomedia.it>
    |ederico Giannici       http://www.neomedia.it
___________________________________________________

_______________________________________________
Serusers mailing list
serusers@lists.iptel.org <mailto:serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers

Greger V. Teigre wrote:

Are you trying to solve NATing for devices behind the same NAT or behind different NATs? If it's the second, you must remember that the NAT problem includes being able to traverse the NAT with packets from the outside. Normally, a symmetric meda stream is based on incoming packets coming on the same port as outgoing and the outgoing must have been initiated first. Couple this with the fact that restricted and port-restricted NATs will stop incoming from other IPs than the source of the outgoing packet and that symmetric will not work anyway, you may be able to solve full cone NATs. However, this is the type of NAT that most STUN clients discover correctly anyway.

I agree with you for the case of symmetric NATs, but they wouldn't work with STUN neither...

For port-restricted NATs I don't understand the problem. If a re-invite is sent to a different IP, then the NAT will be opened for that IP when the UA will start the stream. Don't he?

A problem could be if, for the re-invite, the UA use a different port for RTP then the one used in the previous invite! Is this permitted in the RFC? Is this common in UAs implementation?

Thanks.

Federico Giannici wrote:

...

I'd like to ask to somebody with more knowledge of me if a possible solution to NAT traversal is really feasible.

For various reasons, we DON'T want to use an RTP proxy. We'd like to avoid the use of STUN because: 1) creates hairpin problems; 2) many UAC have a bad STUN client code implementation; 3) it requires additional configuration by the final user.

It seems to me that with the nathelper's message rewriting functions it is possible to solve every problem for the SIP protocol.

Moreover, as we have the REAL IP of the UA (in the original SIP messages) we could also avoid haipin problems: it is sufficient to use the original IP/Port of the two UAs if both have the same natted IP (ie they are behind the same NAT). This doesn't work when the UAs are behind multiple NATs, but this is a relatively uncommon case.

So, the unresolved problem is with the RTP data, because we don't know what will be the NATted port so we cannot correctly mangle the SDP data in the INVITE message.

Am I correct up to this point?

Now, I'm asking myself if it is feasible to use a "MINI RTP Proxy" that receives the initial INVITEs, discovering the NATted RTP ports, and then IMMEDIATLY RE-INVITE the two UAs to connect directly each other. So only the first RTP packet is actually proxed, all subsequent traffic will be directly between the two UAs. I think that something similar is done by Asterisk.

Is this feasible?

If it is, then we could have a good solution to NAT Traversal:

1. No Hairpin problems (for one NAT cases)
2. No problems of the normal RTP proxy (waste of bandwidth, longer

delays, bad scalability). 3) Will work with all type of NATs except for symmetric ones (the same that work with STUN). 4) Simpler UAC configuraton: only username, password and sip server.

Thanks.

Greger V. Teigre wrote:

Exactly, but this is not the UA, it's the NAT allocating the port (you didn't answer whether you are solving the problem of two UAs behind same NAT or behind different NATs).

I don't understand your question.

I'm tring to solve the more general case as possible. Moreover, I'm tring to solve hairpin problems for UAs behind the same NAT (and only one).

All of this without proxing the RTP streams (just a couple of packets).

The UA will probably use the same port, but a reINVITE may even change IP... The problem is the NAT allocating another port on the public interface.

But the various kinds of "cone NATs" should allocate always the same port (for the same internal IP/Port). This is the assumption on which STUN is based!

Bye.