<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> <p class="MsoNormal">That’s a good point: that the port can be remapped.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I’ve observed NAT routers commonly use the same external port as the internal host computer. Router manufacturers certainly should randomize the external port, but I wonder what the actual numbers are. If libnice guessed that the router would use the same port, and if it remembered its external address, it might be work a good amount of the time. If libnice had some degree of memory, it could even keep track of whether it seems to be behind a router that uses the same port externally as internally.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Another option would be to provide an API so that the host process could ask libnice to do the STUN request ahead of time. For example, as soon as a client app is launched it could ask libnice to allocate a port and make a stun request, knowing that the user is probably going to make a call soon. This is rather app dependent, but in many cases the app could correctly anticipate that port allocation and a stun request will not be wasted.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I like the idea of using UPnP if that can streamline port discovery too.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Olivier Crête <olivier.crete@collabora.com><br> <b>Date: </b>Tuesday, October 20, 2020 at 12:29 PM<br> <b>To: </b>Stuart Marshall <stuart@seelye.net>, Fabrice Bellet <fabrice@bellet.info>, Juan Navarro <juan.navarro@gmx.es>, nice@lists.freedesktop.org <nice@lists.freedesktop.org><br> <b>Subject: </b>Re: [libnice] Force an external address (srflx) candidate?<o:p></o:p></span></p> </div> <div> <p class="MsoNormal">Hi,<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">The thing is that the external address might be the same. But on very new connection, the port will be different. And we have no way what kind of mapping from internal to external port the router will chose. From what I understand, it is even recommended to router manufacturer that they randomize the external port to try to make it harder for attackers to guess the next port.<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">So even if we remebered the external address, it wouldn't help so much.<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">What can help, is to build libnice with UPnP support. This way, the external address can be retrieved over the LAN and this is very quick. We could also implement NAT-PMP, which is what Apple routers use. But I don't know if this is common anymore.<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Olivier<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">On Tue, 2020-10-20 at 17:42 +0000, Stuart Marshall wrote:<o:p></o:p></p> </div> <blockquote style="border:none;border-left:solid #729FCF 1.5pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <p class="MsoNormal">I like the idea of doing just one STUN request to avoid the many semi-duplicate candidates.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">Another interesting thing to think about is that in most cases (99.9% ish) the STUN query is going to return the same result as last time. In most cases the host computer has not moved networks and the external address has not changed.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">What if libnice could remember the previous external address and lead with that as a candidate. Libnice could still do one (or more) STUN queries to check if the external address has changed. But starting with the previously known external address could speed up connection a lot.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">The challenge is “how to remember the previous external address”. Libnice lives in somebody’s process and on some random host computer. Libnice might be completely shut down in-between uses, even if the process keeps running.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">What if libnice remembered the previous external address somewhere in process space. If the process shuts down the knowledge is lost. But if the process keeps running (e.g. a server or a long running browser) then the external address is remembered. Is there a cross-platform place to stash data? Environment variables might work. A persistent background thread might work.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">The reason I suggest optimizations like this is customer experience. I see chrome to gstreamer establish connections in less than a second. Gstreamer to gstreamer often takes much more time – easily five seconds plus.<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">Stuart<o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">nice <nice-bounces@lists.freedesktop.org><br> <b>Date: </b>Monday, October 19, 2020 at 11:00 AM<br> <b>To: </b>Stuart Marshall <stuart@seelye.net><br> <b>Cc: </b>Juan Navarro <juan.navarro@gmx.es>, nice@lists.freedesktop.org <nice@lists.freedesktop.org><br> <b>Subject: </b>Re: [libnice] Force an external address (srflx) candidate?</span><o:p></o:p></p> </div> <div> <p class="MsoNormal">Hi Stuart,<br> <br> On 10/14/20 at 09:22pm, Stuart Marshall wrote:<br> > In contrast, the ICE candidates emitted by Chrome are stunningly few and precise. I understand that the ICE protocols and the libnice implementation were/are meant to be general case. But they miss obvious efficiencies that can be provided by additional external information. STUN servers facilitate some of that additional information, but introduce a dependency and more latency.<br> > <br> > My knowledge of libnice internals is not great, but I kind of wish we could<br> > <br> > 1. Feed some particular IP candidate addresses to it,<br> > 2. Tell it to skip a bunch of other candidate generation and testing<br> <br> I think of some optimisations, that could help to limit the number of<br> candidates, without weakening the versatility of the ice method overall<br> (except in *rare* cases where the server running libnice uses source<br> routing, ie chooses the default route based on the source IP address):<br> <br> We could use a single server reflexive candidate and relay local<br> candidate, per stream/component.<br> <br> Generally, there's no gain to send a stun request from each local<br> interface, because all packets will reach the same stun server by the<br> same default route. <br> <br> The consequence is that we obtain <N> distinct server-reflexive<br> candidates from <N> distinct source IP addresses. These<br> server-reflexives candidates are distinct because their IP address will<br> be the same (this is our public IP address), but the port mapping will<br> be different. The same applies to turn relay candidates too (including<br> unnecessary resources reservations on the turn servers BTW).<br> <br> To avoid that, we could for example:<br> 1. discard these redundant candidates when we discover them (when<br> processing the discovery stun response).<br> 2. or more radically, just send a single stun and turn discovery request.<br> <br> In case of 2. the choice of the local interface used as the base address<br> to send this unique stun/turn discoevry request is normally not<br> relevant, because the routing table will hopefully make these packets go<br> out by the same default route again, whatever source interface they come<br> from.<br> <br> To summarize, I think that sending a single stun request from a single<br> network interface during gathering phase to obtain our server-reflexive<br> address is normally a cheap operation (one RTT when the thr stun server<br> is available), but what is expensive from libnice point of view is to<br> deal with many identical reflexive/relay candidates during the<br> connecting phase, because it creates many possibilities to be tested.<br> And the more possibilities we have to test, the more time it takes to<br> complete.<br> <br> Best wishes,<o:p></o:p></p> <pre>_______________________________________________<o:p></o:p></pre> <pre>nice mailing list<o:p></o:p></pre> <p class="MsoNormal"><a href="mailto:nice@lists.freedesktop.org"><o:p></o:p></a></p> <pre><u><span style="color:blue"><a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org<span style="color:windowtext;text-decoration:none"><o:p></o:p></span></a></span></u></pre> <p class="MsoNormal"><o:p> </o:p></p> <pre><o:p> </o:p></pre> <p class="MsoNormal"><a href="https://lists.freedesktop.org/mailman/listinfo/nice"><o:p></o:p></a></p> <pre><u><span style="color:blue"><a href="https://lists.freedesktop.org/mailman/listinfo/nice">https://lists.freedesktop.org/mailman/listinfo/nice<span style="color:windowtext;text-decoration:none"><o:p></o:p></span></a></span></u></pre> <p class="MsoNormal"><o:p> </o:p></p> <pre><o:p> </o:p></pre> </div> </blockquote> <div> <pre>-- <o:p></o:p></pre> <div> <p class="MsoNormal">Olivier Crête<o:p></o:p></p> </div> <div> <p class="MsoNormal"><a href="mailto:olivier.crete@collabora.com">olivier.crete@collabora.com</a><o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> </div> </div> </body> </html>