<div dir="ltr"><div dir="ltr">Thank you for your response to my question, Olivier.</div><div dir="ltr"><br></div><div dir="ltr">I was wondering whether using connect() on an ICE UDP socket (sharing a single port) would alleviate the need to filter at the application level (on the inbound side), but have no idea whether/how that work in practice for ICE.</div><div dir="ltr"><br></div><div dir="ltr">I suspect I may not have an easy time convincing an enterprise organization that they shouldn't need to block, monitor, or filter so many ports, though (when they currently block all inbound/outbound UDP).</div><div dir="ltr"><br></div><div>I recently ran across and wonder whether anything became of this Internet Draft by Jennings et al.<span style="color:rgb(23,43,77);font-family:-apple-system,system-ui,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px">: </span><a href="https://tools.ietf.org/html/draft-jennings-behave-rtcweb-firewall-05" class="external-link" target="_blank" rel="nofollow noopener" title="Follow link" style="color:rgb(0,82,204);font-family:-apple-system,system-ui,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px;outline:none;text-decoration-line:none">https://tools.ietf.org/html/draft-jennings-behave-rtcweb-firewall-05</a> which refers to several reasons why an enterprise might want to block UDP ports, along with a potential 'solution'.</div><div><br></div><div>Thanks again,</div><div>Gary</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 28, 2020 at 11:28 AM Olivier Crête <<a href="mailto:olivier.crete@collabora.com">olivier.crete@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div>Hi,</div><div><br></div><div>There is no such thing in libnice. I don't think it's very valuable to do that, opening UDP ports in a firewall costs nothing, and really has no added risk, especially if you target a specific computer. If you were to re-use the port, you'd have to do the filtering in userspace and waste quite a bit of CPU resources.</div><div><br></div><div>The one real reason to have multiple connections negotiated from the same local socket is to be able to do SIP call forking, but I haven't seen anyone implement that with ICE.</div><div><br></div><div>Olivier</div><div><br></div><div>On Fri, 2020-02-28 at 10:43 -0800, Gary Bartlett wrote:</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">I'm wondering whether libnice supports the notion of sharing/reusing UDP ports for its ICE candidates, so that only a single (or small set of) UDP ports can be opened up for it in a firewall?<br><br>It sounds like if I reduce the range of available UDP ports by calling nice_agent_set_port_range, then this will limit the number of active sessions, but if the ports were reusable (e.g. using SO_REUSEADDR or SO_REUSEPORT), do you think libnice could handle multiple concurrent connectivity checks and WebRTC sessions on this single (or reduced set of) local port(s)?<br></div></div></blockquote></div>
</blockquote></div></div>