<div>NAT traversal, what a fun topic.    </div>
<div><br>See <a href="http://en.wikipedia.org/wiki/UDP_hole_punching">http://en.wikipedia.org/wiki/UDP_hole_punching</a></div>
<div>See <a href="http://www.bford.info/pub/net/p2pnat/">http://www.bford.info/pub/net/p2pnat/</a></div>
<div> </div>
<div>The second of the two links goes into real detail.</div>
<div> </div>
<div>In TCP it's mostly useful when 'both' parties are behind a NAT router, however.   Less useful when just one is because the one computer that's behind a NAT router can be told to do the 'connecting' to the public one. </div>

<div> </div>
<div>The problem, is, it's a hack :D.  Sure, Skype use this hack to peer2peer connect callers.</div>
<div> </div>
<div>Are we planning on having direct end2end communications without a publically available audio proxying server?</div>
<div> </div>
<div>Remember if we are, we'll still need the publically available NAT Traversal coordinator that does the 'trick'.</div>
<div> </div>
<div>Best Regards</div>
<div> </div>
<div>Ter</div>
<div><br> </div>
<div><span class="gmail_quote">On 2/27/08, <b class="gmail_sendername">Dr Scofield</b> <<a href="mailto:DrScofield@xyzzyxyzzy.net">DrScofield@xyzzyxyzzy.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Sean Dague wrote:<br>> I've spent a little bit of time looking at the Voice Module that just<br>> got moved into trunk from the RealXtend branch, and I think it's headed<br>
> in the wrong direction.<br>><br>> Embedding voice in the simulator seems like the wrong direction, and<br>> much less modular than we were heading for.  Plus, I think that under<br>> any reasonable load, it's going to go useless *real fast*.  Given that<br>
> chat messages can often take 30 seconds in a loaded message, nothing<br>> like voice really belongs there.<br>><br>> I think a much better approach would be to carve off voice functionality<br>> into a seperate VoiceServer, which would let it run on a dedicated<br>
> machine, ensuring low latency.  I also think that the SLVoice approach<br>> of sending all the streams to the client and letting the client do the<br>> mixing is a better load approach.<br>><br>ansi and i are working on getting the voice caps working from the<br>
opensim side, so that we can then substitute the vivox daemon without<br>the SL client noticing (that's the plan anyhow).<br>> Perhaps a hybrid model where after significant avatar moves avatar<br>> possitions were sent to the Voice Server, so that you don't have the<br>
> issue where your ears can be fully devoid of your camera, would be<br>> best.  But at the end of the day doing mixing on the server just seems<br>> wrong.  Even skype offloads this to clients to do.<br>><br>
completely agree.<br><br>   cheers,<br>   dr scofield/aka dirk<br><br>--<br>dr dirk husemann ---- math & computer science ---- ibm zurich research lab<br>RL: <a href="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</a> - +41 44 724 8573 - <a href="http://www.zurich.ibm.com/~hud/">http://www.zurich.ibm.com/~hud/</a><br>
SL: <a href="mailto:drscofield@xyzzyxyzzy.net">drscofield@xyzzyxyzzy.net</a> --------------------- <a href="http://xyzzyxyzzy.net/">http://xyzzyxyzzy.net/</a><br><br>_______________________________________________<br>Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></blockquote></div>
<br>