<div dir="ltr"><div>Yep, single port on FS side. Multiple ports could be still fine (I guess) but not sure if the ease the situation. Where do you see serious performance impacts? As far as I know, SO_REUSEPORT data flow is switched by the kernel with a hash (maybe you mean this hash calculation on every RTP packet?).<br></div>Trying out a turn server is a great idea, I will research that a bit, thank you.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 January 2017 at 19:32, Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">sorry.. doing 2 things at once. thats addr not port. Are you saying you want to use a single port on the freeswitch side? If so, that would be a major change with serious performance impacts. We wouldn’t be interested in that, but you can try doing it with a turn server maybe.<div><div class="h5"><div><br></div><div><br><div><blockquote type="cite"><div>On Jan 23, 2017, at 1:24 PM, Michael Jerris <<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>> wrote:</div><br class="m_-2322165076184336819Apple-interchange-newline"><div><div style="word-wrap:break-word">on second thought….<div><br></div><div><div style="margin:0px;font-size:13px;line-height:normal;font-family:Monaco;color:rgb(244,244,244);background-color:rgba(0,0,0,0.85098)"><span style="font-variant-ligatures:no-common-ligatures">src/switch_rtp.c</span><span style="font-variant-ligatures:no-common-ligatures;color:#34bbc8">:</span><span style="font-variant-ligatures:no-common-ligatures">2594</span><span style="font-variant-ligatures:no-common-ligatures;color:#34bbc8">:</span><span style="font-variant-ligatures:no-common-ligatures"> if (switch_socket_opt_set(rtcp_<wbr>new_sock, SWITCH_SO_</span><span style="font-variant-ligatures:no-common-ligatures;color:#c33720">REUSE</span><span style="font-variant-ligatures:no-common-ligatures">ADDR, 1) != SWITCH_STATUS_SUCCESS) {</span></div><div style="margin:0px;font-size:13px;line-height:normal;font-family:Monaco;color:rgb(244,244,244);background-color:rgba(0,0,0,0.85098)"><span style="font-variant-ligatures:no-common-ligatures">src/switch_rtp.c</span><span style="font-variant-ligatures:no-common-ligatures;color:#34bbc8">:</span><span style="font-variant-ligatures:no-common-ligatures">2690</span><span style="font-variant-ligatures:no-common-ligatures;color:#34bbc8">:</span><span style="font-variant-ligatures:no-common-ligatures"> if (switch_socket_opt_set(new_<wbr>sock, SWITCH_SO_</span><span style="font-variant-ligatures:no-common-ligatures;color:#c33720">REUSE</span><span style="font-variant-ligatures:no-common-ligatures">ADDR, 1) != SWITCH_STATUS_SUCCESS) {</span></div></div><div><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div>it’s already there.</div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Jan 23, 2017, at 1:22 PM, Michael Jerris <<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>> wrote:</div><br class="m_-2322165076184336819Apple-interchange-newline"><div><div style="word-wrap:break-word">we’d look at it at least.<div><br><div><blockquote type="cite"><div>On Jan 23, 2017, at 1:16 PM, Tamas Jalsovszky <<a href="mailto:jalsot@gmail.com" target="_blank">jalsot@gmail.com</a>> wrote:</div><br class="m_-2322165076184336819Apple-interchange-newline"><div><div dir="ltr"><div>I can just agree with your statement. Unfortunately this is not my/our brain-dead policy or rule but a few corporate firewall "specialists'", and having no influence on it. <br><br></div>If somebody provides a patch, would you merge it or you would bar any such a complication?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 January 2017 at 19:01, Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This adds zero value to security and adds lots of possibilities of failed calls. Seems like a complete waste of time to me. Education on what is and is not secure and why blocking more ports that are not listening adds zero to security seems a much more useful way to use time<br>
<div><div class="m_-2322165076184336819h5"><br>
> On Jan 23, 2017, at 10:02 AM, Tamas Jalsovszky <<a href="mailto:jalsot@gmail.com" target="_blank">jalsot@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> I have a few places where using a SIP (or webrtc) endpoint demands opening up the very restrictive local network firewall. Setting rtp port range would be the way to go, however usually the simple math (e.g. setting the range for 2x the number of endpoints) is still not welcomed by local network admins - paranoid ones :)<br>
><br>
> My idea here is whether we could use SO_REUSEPORT in the RTP stack (I've found in sofia lib the conditional use of this option) and possibly setting a very short range for RTP or even setting only one port (I'm not sure about RTCP) as from the other side packets come from the same IP but from different port, e.g.<br>
> IPclient:PortA -> IPFSserver:PortX<br>
> IPclient:PortB -> IPFSserver:PortX<br>
> IPclient:PortC -> IPFSserver:PortX<br>
> etc.<br>
><br>
> What do you think, would it be doable? If not, any other way to rapidly lower the port range to be set at the endpoint side?<br>
><br>
> Regards,<br>
> Jalsot<br>
><br>
<br>
<br>
</div></div>______________________________<wbr>______________________________<wbr>_____________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com/" rel="noreferrer" target="_blank">http://www.freeswitchsolutions<wbr>.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org/" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org/" rel="noreferrer" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com/" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitc<wbr>h.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" rel="noreferrer" target="_blank">http://lists.freeswitch.org/ma<wbr>ilman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" rel="noreferrer" target="_blank">http://lists.frees<wbr>witch.org/mailman/options/<wbr>freeswitch-dev</a><br>
<a href="http://www.freeswitch.org/" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br></div>
______________________________<wbr>______________________________<wbr>_____________<br>Professional FreeSWITCH Consulting Services:<br><a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br><a href="http://www.freeswitchsolutions.com/" target="_blank">http://www.<wbr>freeswitchsolutions.com</a><br><br>Official FreeSWITCH Sites<br><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br><a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br><a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br><br>FreeSWITCH-dev mailing list<br><a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.<wbr>freeswitch.org</a><br><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/<wbr>mailman/listinfo/freeswitch-<wbr>dev</a><br>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.<wbr>freeswitch.org/mailman/<wbr>options/freeswitch-dev</a><br><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></div><br>______________________________<wbr>______________________________<wbr>_____________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.<wbr>freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" rel="noreferrer" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.<wbr>freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" rel="noreferrer" target="_blank">http://lists.freeswitch.org/<wbr>mailman/listinfo/freeswitch-<wbr>dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" rel="noreferrer" target="_blank">http://lists.<wbr>freeswitch.org/mailman/<wbr>options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>