<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
A NAT can be:<br>
- "Outbound refresh": keep the mapping active when a packet goes from
the internal side of the NAT to external side<br>
- "Inbound Refresh": keep the mapping active when a packet goes from
the external side of the NAT to internal side <br>
or both!<br>
<br>
Moreover the NAT Mapping Refresh Scope can be:<br>
- "Per Mapping": refresh for all session on that mapping by any
outbound traffic<br>
- "Per Session": refresh on a specific session on that particular
mapping by any outbound traffic<br>
<br>
So, when you refresh with a 20-second period (a good delay) you must
consider also this.<br>
<br>
Have fun,<br>
-- Luca<br>
<pre wrap="">
______________________________________________
Luca Gaballo - <span id="mail-highlight-id"
style="background-color: yellow;">France</span> Telecom - R&D Division
Email: luca.gaballo@rd.<span id="mail-highlight-id"
style="background-color: yellow;">france</span>telecom.com
Peer networks - Solipsis Project
<a class="moz-txt-link-freetext" href="http://solipsis.netofpeers.net/">http://solipsis.netofpeers.net/</a>
Personal web: <a href="http://perso.enst.fr/%7Egaballo">http://perso.enst.fr/~gaballo</a>
</pre>
<br>
David Barrett wrote:
<blockquote cite="mid42A3ABEC.8070000@quinthar.com" type="cite">Ok,
next question: What kind of keepalive period do you used to maintain
the holes you so meticulously punched? <br>
<br>
I'm in the process of testing my NAT hole-punching solution, and I'm
finding erratic behavior that I *think* is caused by my holes closing
on me. (Ie, I'm able to receive from a peer for a time, and then I
cannot.) So I'm implementing a keepalive, but I'm unsure of what
period to use. For now I'm just using a fixed 20-second period, but I
have no idea if that's high or low. <br>
<br>
Another option is to have some kind of adaptive solution that tracks
elapsed time between sent and received data (thus estimating the last
known 'good' window), but that's a pain I'd prefer to avoid. <br>
<br>
Any suggestions? <br>
<br>
The IETF BEHAVE group has discussed recommendations from anywhere
between 30 seconds
(<a class="moz-txt-link-freetext"
href="http://list.sipfoundry.org/archive/ietf-behave/msg00441.html">http://list.sipfoundry.org/archive/ietf-behave/msg00441.html</a>)
and 15
minutes (<a class="moz-txt-link-freetext"
href="http://list.sipfoundry.org/archive/ietf-behave/msg00127.html">http://list.sipfoundry.org/archive/ietf-behave/msg00127.html</a>).
But ultimately those are foward-looking discussions, and therefore not
relevant. <br>
<br>
In the real world, I've seen mention that even 30 seconds is
insufficient
(<a class="moz-txt-link-freetext"
href="http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119">http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119</a>).
Perhaps 20 seconds works
(<a class="moz-txt-link-freetext"
href="http://www.tisc2001.com/newsletters/322.html">http://www.tisc2001.com/newsletters/322.html</a>),
but who knows. <br>
<br>
Basically, I'm curious what keepalives you've found work today in your
real applications, in the real world. <br>
<br>
-david <br>
_______________________________________________ <br>
p2p-hackers mailing list <br>
<a class="moz-txt-link-abbreviated" href="mailto:p2p-hackers@zgp.org">p2p-hackers@zgp.org</a>
<br>
<a class="moz-txt-link-freetext"
href="http://zgp.org/mailman/listinfo/p2p-hackers">http://zgp.org/mailman/listinfo/p2p-hackers</a>
<br>
_______________________________________________ <br>
Here is a web page listing P2P Conferences: <br>
<a class="moz-txt-link-freetext"
href="http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences">http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences</a>
<br>
<br>
</blockquote>
<br>
<br>
</body>
</html>