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.<br><br><div><span class="gmail_quote">On 8/31/05, <b class="gmail_sendername">Federico Giannici</b> <<a href="mailto:giannici@neomedia.it">giannici@neomedia.it</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'd like to ask to somebody with more knowledge of me if a possible<br>solution to NAT traversal is really feasible.
<br><br>For various reasons, we DON'T want to use an RTP proxy.<br>We'd like to avoid the use of STUN because: 1) creates hairpin problems;<br>2) many UAC have a bad STUN client code implementation; 3) it requires<br>additional configuration by the final user.
<br><br>It seems to me that with the nathelper's message rewriting functions it<br>is possible to solve every problem for the SIP protocol.<br><br>Moreover, as we have the REAL IP of the UA (in the original SIP<br>messages) we could also avoid haipin problems: it is sufficient to use
<br>the original IP/Port of the two UAs if both have the same natted IP (ie<br>they are behind the same NAT). This doesn't work when the UAs are behind<br>multiple NATs, but this is a relatively uncommon case.<br><br>So, the unresolved problem is with the RTP data, because we don't know
<br>what will be the NATted port so we cannot correctly mangle the SDP data<br>in the INVITE message.<br><br>Am I correct up to this point?<br><br>Now, I'm asking myself if it is feasible to use a "MINI RTP Proxy" that
<br>receives the initial INVITEs, discovering the NATted RTP ports, and then<br>IMMEDIATLY RE-INVITE the two UAs to connect directly each other. So only<br>the first RTP packet is actually proxed, all subsequent traffic will be
<br>directly between the two UAs.<br>I think that something similar is done by Asterisk.<br><br>Is this feasible?<br><br>If it is, then we could have a good solution to NAT Traversal:<br>1) No Hairpin problems (for one NAT cases)
<br>2) No problems of the normal RTP proxy (waste of bandwidth, longer<br>delays, bad scalability).<br>3) Will work with all type of NATs except for symmetric ones (the same<br>that work with STUN).<br>4) Simpler UAC configuraton: only username, password and sip server.
<br><br><br>Thanks.<br><br>--<br>___________________________________________________<br> __<br> |- <a href="mailto:giannici@neomedia.it">giannici@neomedia.it</a><br> |ederico Giannici <a href="http://www.neomedia.it">
http://www.neomedia.it</a><br>___________________________________________________<br><br>_______________________________________________<br>Serusers mailing list<br><a href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a>
<br><a href="http://lists.iptel.org/mailman/listinfo/serusers">http://mail.iptel.org/mailman/listinfo/serusers</a><br></blockquote></div><br>